Predefined fields and Extra fields unification.

[macik]

:us: This is not nearest future request but some future requirement…

Now we move toward internal Cotonti unification and modules API. This is good direction. Lets talk about Extra fields and fields management at all. Inspite of great Extrafields functionality developer still had a lot of «handmade» work.

Current state

Problem 1: If plugin adds and use some extrafields there are need to manually update coresponding templates (one for add form, second for edit form) to insert each field and repeat that steps for every theme used with a site.

Problem 2: Now bigger part of form/fields management logic is located in templates. So we don't have ability to manage this with addition plugins/modules, or simply adding extrafields.

Problem 3: We had big inconsistency within plugin data fields. Predefined fields had not standarded naming convention (see related #1152) and ability to get list of predefined fields. As Predefined fields and Extra fields are the same by origin (except predefined fields are protected from deletion and edit) we need same (standard) way to work it as extra fields had.

Suggestion:

As HTML code across common site forms mainly the same we can generate if using programm code use one tag for whole form. And manage it through API and UI (like Extrafields does) and set whether certain field should be visible in add/edit form.

As a first step: Unified form generation api. Make predefined fields to treat as common (extra) fields with some limitations.

As the second step: Extend field management UI (based on extra fields UI). Add controls to set whether certain field should be visible in add/edit form. And manage fields view order across certain form.

As the third step: Extend (unified) method of form tags processing and generation. Extend form tags with {*_FORM_FIELDS} and {*_FORM} (generated with UI manages rules) to simplify theme templates support.

Benefits:

1. We can eliminate code duplacation used for fields and extra fields generation in different modules used forms (page, forums, pm, user or custom ones).
2. We move logic of HTML form generation from templates to module/plugs code, where it should be.
3. This is right direction toward ORM use.
4. We get a good base for CСK developments (content construction kit).

---

in russian :ru:

Текущая концепция не предполагает немедленного внедрения, но на мой взгляд, это то, без чего не возможно развитие и расширение движка в будущем...

Сейчас развитие идет в сторону унификации внутренних механизмов и создания стандартизированных API у модулей и плагинов. Это правильная тенденция. Одним из удобных механизмов являются экстраполя. Но несмотря на их потенциал разработчик все еще завален рутиной ручных операций.

Текущее состояние

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

Проблема № 2: Сейчас большая часть логики управления формами и полями форм находится в шаблонах. Таким образом мы не можем влиять на функционал из установленного плагина или просто создав экстраполе.

Проблема № 3: Сейчас мы имеем серьезную несовместимость между полями по умолчанию (стандартными или другими словами предустановленными) и экстраполями. Для стандартных полей нет четких правил формирования (частично описано в #1152 ). Нет простой возможности программно получить список стандартных полей. Из-за чего приходится писать обработчики стандартных полей для каждого поля в отдельности (см. пример ). Предопределенные поля и дополнительные поля очень схожи по своей сути (разница только в том, что предопределенные поля защищены от удаления и редактирования). Но у нас нет возможности работать с ними так же просто как с дополнительными полями.

Предложения:

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

В качестве первого шага можно: Дополнить API создания форм. Приравнять стандартные поля (с определенными ограничениями) к экстраполям и трактовать и обрабатывать из как экстраполя.

В качестве второго этапа: Расширить интерфейс управления полями (на основе интерфейса управления дополнительными полями). Добавить элементы управления, чтобы можно было установить какие поля должны быть видны в форме добавления/редактирования и в каком порядке.

Третий шаг: Расширить методы создания тегов полей, методами создания тегов форм. Для упрощения поддержки шаблонов тем расширить набор тегов форм, добавив к формирования тегов полей теги форм {*_FORM_FIELDS } (все поля формы) и {*_FORM } (форма целиком) на основе правил (установленных программно или через UI) .

Преимущества:

  1. Реализовав предложенное мы избавимся от дублирования однотипного кода для генерации полей и экстраполей в различных модулях.   2. Мы перенесем логику отображения форм и полей форм в код модуллей/плагинов (туда где она и должна быть).   3. Продвинемся еще на один шаг вперед к созданию ORM.   4. Получим хорошую базу для развития CСK (content construction kit) — базового модуля для создания на его основе модулей управления контентом (страницы, форумы, товары и т.д.).

[esclkm]

disagree. Missunderstand reasons вообще не по-русски. простите за мой русский. Может плохо читаю... но с мыслями не согласен ,часть из этого есть https://github.com/Cotonti/Cotonti/blob/master/modules/page/inc/page.edit.php#L185-L198

[macik]

[to @esclkm : я как раз, в том числе и говорю о том, чтобы расширить приведенный подход на обработку всех полей данных.]

I take into account this code. And one part of my concept is to cut down main fields processing code to extrafields-like (as shown above)

[to @esclkm : Перечитай еще раз. Я не предлагаю переделывать, я предлагаю расширить. Если все же не согласен аргументируй по пунктам.]

[Kilandor]

The ability to be able to control and choose what fields show on pages via a gui and from inside Cotonti would be nice to some extent. This would be a difficult undertaking.

The user would still already have to design the html and setup for making it work in their template. If I read right, you want all fields to have this feature, which pretty much means rewriting everything that shows tags everywhere. The only way to prevent it from having to process this every time. You would be forced to create a system to store a cache of the new template with the wanted data that is used to parse out the data, else it has to check/build which ones to show everytime. To which this template could be updated on changes.

Now as far as code cleanup for duplicate code for displaying extrafields. You can clean that up very easily. They should already be a completely standard format, if not then just fix it so they are, users will just have to update templates.

You simply need to create a function that takes input of all the needed data. It will require alot of arguments, but you can standardize it easily and then cutout all handling and parsing of tags for extrafields. As well as simple case of a needing to parse to a different template than $t a final argument can be used to return an array of tag data for custom parsing as needed.

I use similar method for my shop plugin. I have alot of data identical used across alot of area's. So I setup functions to take inputs to handle template parsing, tags, data and display. In case of I send out some emails and have 2 different tpls being parsed at the same time I simply return the data but still get to use the function. So yes done right you can save hundreds of lines of code.

[macik]

Not at all…

Yes, the basic concept is to unified internal fields across itself. So I can (as a developer) use clean and simple API to use core fields of modules (like extrafields API does for extra fields) to easy build some extension for core modules. (Now I can't do that due to #1152).

But I suggest to extend tag generation process rathar than rewrite it. So old (current) styles of form tags still be possible to use without changes. It'll be intakt.

        <div class="form-group">
          <label class="control-label">{PHP.L.Title}:</label>
          {PAGEADD_FORM_TITLE}
        </div>

But new tags allow to simplify this, with something like:

       {PAGEADD_FORMFILED_TITLE}

thats do the same thing.

Or even {PAGEADD_FORM} for whole table.

And we do not need to rearrange several tamplates while adding one new extrafield. And can manage it through programming code.

[seditio]

Was discussed long time ago: the page tags like PAGE_SHORTTITLE and PAGE_TITLE (LIST_CATTITLE / PAGE_ROW_SHORTTITLE etc). I still confuse theme. Why not reviewing the names in favor of just _TITLE (or whatever) and introduce _BREADCRUMBS (or whatever) to differentiate between plain titles and (poorly) generated link chains? Maybe use a separate plugin for breadcrumbs. For a major build, of course.