Forums / National / Russian / Тех. поддержка / Как подключить функции к полям форм?

Izhver
#1 2013-12-25 14:25

Бился бился, так и не смог подключить форму. Чувствую, что просто но никак не врубаюсь. 
Есть код формы, надо подключить функцию поля. Скажем создать сложную форму обратной связи + регистрация.
Понимаю, что можно создать экстраполя. Но они создаются внутри плагина. А как подключить функцию экстраполя к другому шаблону или это невозможно?
Спасибо.
Вот код формы: 
<div class="container">
    <form class="well span8">
        <div class="row">
            <div class="span3">
                <label>First Name</label> <input class="span3" placeholder=
                "Your First Name" type="text"> <label>Last Name</label>
                <input class="span3" placeholder="Your Last Name" type="text">
                <label>Email Address</label> <input class="span3" placeholder=
                "Your email address" type="text"> <label>Subject</label>
                <select class="span3" id="subject" name="subject">
                    <option selected value="na">
                        Choose One:
                    </option>
    
                    <option value="service">
                        General Customer Service
                    </option>
    
                    <option value="suggestions">
                        Suggestions
                    </option>
    
                    <option value="product">
                        Product Support
                    </option>
                </select>
            </div>
    
            <div class="span5">
                <label>Message</label> 
                <textarea class="input-xlarge span5" id="message" name="message"
                rows="10">
    </textarea>
            </div><button class="btn btn-primary pull-right" type=
            "submit">Send</button>
        </div>
    </form>
</div>

Macik
#2 2013-12-26 00:06

Если коротко, то не возможно. Т.к. (в обычном случае) не «шаблон управляет кодом», а «код формирует страницу на основе шаблона».Т.е. просто дополнив шаблон не возникнит код, который будет его обрабатывать.

Иными словами, в любом случае придется писать дополнительный код.

[Далее теория применительно к формам и их использованию, просто чтобы понимать всю механику работы…]

Как работают формы? У нас есть клиентская часть (html-форма), которую может частично или полностью генерить сервер и серверная (плагин или модуль), код который будет обрабатывать данные из формы. 
Если мы пишем 
полностью свой плагин — тут (условно) проблем нет. Делаем любую форму и программируем любую фукнкциональность. Это оптимальный вариант для расширения. Другое дело, если мы хотим использовать чать функциональности уже готового плагина, расширив его. 

 

Задача распадается на две составляющие: расширение html кода формы (клиентской части) и расширение серверной части по обработке данных. Для начала  надо определить, что именно будем расширять и какой плагин или модуль использовать.  

 

Расширение кода форм

Откуда берется код формы? Тут несколько вариантов:

  1. код формы полностью генерируется в коде php или вшит как строчные данные в код php. — в Котонти это практически не применяется и так делать не надо.
  2. код формы содержится в шаблоне (tpl) в исходном виде (в виде html) — пример `ratings.tpl`
  3. код формы содержится в шаблоне (tpl) в виде тегов для каждого из полей формы — пример `contact.tpl`

Как расширить? 

Первый вариант не рассматриваю, т.к. это «oldschool» и «bad practice» для Котонти.
Второй и третий варианты можно расширить за счет изменения шаблона. 
Т.е. добавляем свои доп.поля в виде «голого» html-кода. Правим либо шаблон плагина (менее предпочтительно), либо делаем копию шаблона правим ее, размещая в папке `themes/your_theme/plugins/plugin_name/plugin_name.tpl` или `themes/your_theme/plugins/plugin_name.tpl` (более предпочтительный вариант). 

Еще более предпочтительный метод расширения форм (но работает только для части плагинов третьего пункта) — это использование экстра-полей плагина. Это облегчает работу, т.к. надо только добавить тег экстраполя в шаблон, а движок сам возьмет на себя заботу о том, чтобы создать дополнительное поле в форме, а потом созранить данные в базе данных.

Но надо с этими данными еще что-то делать. Тут мы переходим ко второй части…

Расширение серверного кода

[Теория] Плагины в рамках Котонти используют различные подходы к проектированию: 

  • standalone, когда код плагина вызывается только при запросе пользователем конкретной страницы и берет на себя «полное управление» включая вывод шаблонов (отрисовку содержимого страницы). Вызвать такой код из другого места программы или другой страницы практически невозможно. Например плагин `contact`.
  • функциональный подход заключается в использовании набора функций реализующих часть функционала. Такой код можно (при определенных условиях) вызывать из любого места скрипта (любой страницы). Этот подход в полной мере реализуют «плагины-виджеты», например `attach2`, когда вызывая функцию мы получаем часть клиентского кода (в данном случае виджет загрузки файлов) и можем включить его в произвольное место своей страницы.
  • смешанный подход, реализующий в себе оба предыдущих варианта. Такой подход используют многие модули, например модель `page`.

Как расширить функционал? 

Глобально есть 2 метода расширения плохой и хороший: 
Плохой — это взять код готового плагина и расширить/изменить под свои нужды. Плох он тем, что будет трудно поддерживать совместимость при выходе новых версий плагина или системы.
Хороший — создать свое расширение (маленький плагин) дополняющий функции текущего плагина (если есть соотв. хуки).

В Котонти основным методом расширения являются хуки (hooks). И расширить функции системы проблем нет — выбираем подходящую точку входа (хук) и пишем код. А вот расширить функционал конкретного плагина сложнее, т.к. авторы плагинов не всегда думают о возможности расширения, и не делают хуков. (Хорошим исключением являются штатные модули системы, где авторы предусмотрели возможность расширения как с точки зрения экстраполей, так и хуков).

......................................................

Теперь, когда общая схема ясна, посмотрим предметно на задачу «форма обратной связи + регистрация». 

Это плагины `contact` и модуль `users`. И тот и другой модуль позволяют создать экстраполя это хорошо. Но не дают в полной мере использовать свой код из другого плагина. В модуле есть хуки, но в плагине их совсем нет. Т.е. нет «простого варианта», создать свой модуль и просто вызвать две функции («регистрация пользвоателя» и «отправка обратной связи»).

Тем не менее Котонти гибок и всегда есть варианты (описываю кратко суть):

  1. Пишем свой плагин полностью, копируя кусками код `contact` и `users`. (громоздко и потребует поддержки при изменении механизмов регистрации или отправки писем).
  2. Пишем свой плагин, вешая его на `users.registe.*` хук(и). расширяем форму регистрации формой обратной связи. вызываем код `contact` внутри своей ф-и обертки. 
  3. расширяем форму регистрации формой обратной связи. Пишем клиентский скрипт (на JS), который перед отправкой данных для регистрации пользователя будет делать AJAX запрос на отправку письма обратной связи, если все ок отправлять форму (как если бы пользователь просто регистрировался), если нет выводить ошибки в соотв. полях.

 

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F
Izhver
#3 2013-12-26 08:01

Величайший респект. Поболше бы таких развернутых пояснений. 

Скажите,а такого рода подходы не вызывают затруднений при верстке сайтов? Это ж довольно затруднительные пути. Может есть общий мануал для верстальщика?

Macik
#4 2013-12-26 10:37

Тут надо понимать какие задачи поставлены перед верстальщиком (какие цели он преследует), и что входит в его компетенцию. Т.к. разработка/создание сайта процесс комплексный.

У меня цикл разработки примерно такой (если мы говорим о создании сайта целиком от и до):

  1. разрботка функциональной модели сайта (т.е. определение задач, которые сайт должен решать)
  2. определение структуры сайта исходя из задач. Грубо говоря определение разделов, которые необходимы(новости, форум, статьи, галерея, пр.)
  3. подбор готовых модулей, плагинов под выбранные задачи и структуру,
  4. прикидка по объему функционала, который надо будет дописывать/дорабатывать, разработка схемы дополнительных модулей
  5. разработка общего оформления сайта (то, что обычно называют дизайном)
  6. корректировка под выбранную структуру и модель (как правило отрисовывается главная страница, если она списывается в общий «дизайн», затем страницы отдельных разделов, особенно если они отличаются от главной по компоновке более чем на 20-25%) 
  7. (вот только после этого начинается) непосредственно верстка — перевод графических образов «дизайна» в код html/css/js. на выходе получаем главную и сопутствующие страницы в виде html шаблона.
  8. (опционально) если на сайте присутствуют сложные формы или другой «не простой» UI, то для него создается отдельный функциональный макет в виде все того же html/css/js.
  9. настройка базовой CMS (+необзодимые модули/плагины)
  10. программирование дополнительного функционала (исходя из п.4). Отработка типовых сценариев работы. Корректирвоака.
  11. отладка основной функциональной части сайта (все что может быть реализовано без кончного дизайна)
  12. создание темы оформления («theme») для Cotonti. — на основе html шаблона (п.7) создаем tpl шаблоны для темы. Начинаем с главной, затем для всех разделов (из п.2), т.е. для каждого из вовлеченных модулей/плагинов. Если упростить, то это замена html кода тегами Cotonti, для вставки в шаблон данных или динамических блоков. Этот этап выполняет уже не «верстальщик», а программист/разработчик (или верстальщик, если он совмещает в себе эти функции).
  13. Отладка всего функционала в законченном дизайне. Корректировка оформления, программной части.

Упрощая — идем от задач сайта через программирование модели к финальному результату. От программной части к оформительской. И только так.

 

https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F