Form Builder

[Alexander Obuhovich]

Recently I was thinking about how hard it is to customize a form (in Admin Console).

Right now when a ModuleA wants to customize a form from ModuleB it copied TPL file to it and makes necessary changes, like this:

1. moduleA/sample_form.tpl
2. copy "moduleA/sample_form.tpl" to "moduleB" folder
3. change "moduleB/moduleA/sample_form.tpl"

This will work, but when original template in moduleA is changed (e.g. during upgrade to next version), then no changes are propagated to copied template.

I'm suggesting a concept of "Form Builder", where you actually define what is located where in a manageable format (e.g. in PHP array format) and then each module can customize that configuration (add/remove fields where it needs).

Basically each form in admin console consists of 3 blocks:

• header - usually not changed
• toolbar definition - buttons you see on a toolbar
• subsections with form elements - that's changed usually

This all will keep single column layout.

I guess we need to visual editor to build that array, like this one: http://www.wufoo.com/docs/form-builder/

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Phil -- wbtc.fr --]

it's true that our actual approach for form building is closer to programer knwoledge, rather than user habits.

Wufoo have a nice intuitive interface, what we exactly miss for all admin interface (sorry, twice said this month!).

Movable elements using mouse to set their display order would be a must. See also Wordpress about this kind of behavior.

2011/11/13 Alexander Obuhovich <aik....@gmail.com>

[Dmitry A.]

Hi guys,

Sounds interesting, but here are some of the thoughts that popped up in my mind:

- How customizable this will be?

This interface approach somewhat reminds me about Stylesheets section we have recently get rid of. The main issue was that at some point it was easier to change things by hand rather then via interfaces. Agree this interface may be more intelligent than deprecated Stylesheets one, but at the same time what if we really need to deliver more then a standard 1 column look?

- Does it really worth the effort?

What exactly we are gaining at this point - ability to have a form created faster via special interfaces, but what's a point of it if you still need to CODE: Database and Business Logic. Basically, what I am trying to say here - let's say we have a Form Builder with ability to create that forms and created a couple of them, but you can't really do much with them - you still need to program DB, Unit Classes and do some Front-end work. 

To summarize, this rises 2 questions:

1. Will actual NON-PHP users able to do the full 'start-to-finish' work if they use Form Builder?

2. Will actual PHP Programmers gain much advantage (counting development time + flexibility)  work if the use Form Builder?

Let me know what you think.

DA

[Alexander Obuhovich]

I've spoken with Dmitry about this over the phone and here are some new info about this.

1. Problem: impossible to change ModuleA module's form by ModuleB module and ModuleC module at the same time (e.g. ModuleB adds FieldB and ModuleC adds FieldC).
2. Solution: make form fields defined as array, so both modules can change it without even changing a template (same idea as with "editing tabs" right now)
3. Bonus to solution: have visual interface for building initial array of fields on the form, that can improve productivity

We use similar approach with grids - grid template isn't changed at all and any module can add/remove fields from it.

This task http://tracker.in-portal.org/view.php?id=270 was created long ago and describes the way how form could be integrated into layout.

About layouts:

We can have an array for this too. This whole layout basically would be a HTML table at the end and we can specify what fields from the form would go to what cell.

This task http://tracker.in-portal.org/view.php?id=269 was created long ago and has more details about form layout concept.

I guess time came, when we can fully understand benefits of this idea.

[Phil -- wbtc.fr --]

wow, you were starting to go in the right direction 2 years ago !

it seems a nice solution, I'll be happy to test it :)

2011/11/14 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

Another idea just came to me. We can store that form configuration in database too, so we can have multiple configuration for a single form (e.g. each one associated with an "Interface Preset").

[Phil -- wbtc.fr --]

interface presets... hmmmmm sounds good :)

[Alexander Obuhovich]

This would be the sample design of form builder (see attached image).

Basically it's a wizard that guides user/developer through all necessary steps to create:

• database table
• table definition in unit config
• grid definition in unit config

Sorry if none of the text from them image is readable. I've tried to use wireframing software, but it fails when I try to create a grid from form controls.

[Dmitry A.]

Hi Alex,

Thanks for taking time to think and draw your ideas. I personally find it very clever idea/drawing.

I think I am definitely up for this, but let's do more homework on this before finalizing it. I propose we explore all ideas and options such as:

1. Customization - ability to customize that already been created using Form Builder (or Unit Builder if we taking it to a next level) at any level (ie. Add/Edit template with option to have specific tags and not auto-printed as default).

2. Unit Config Generator - this can be part of the same process?

Overall, I think we need to step back a little and workout List of Requirements first and then do Brainstorming sessions to come up with all sort of ideas to satisfy those requirements. 

DA

[Alexander Obuhovich]

As you might have noticed I've incorporated some steps from "unit config builder" to make universal wizard for new section creation.

There could be some problems with editing existing TPLs/Unit Configs, since if user have manually edited TPL/PHP part, e.g. added option, that wizard doesn't know about, then it will most probably overwrite it.

We could move part of TPL/PHP as serialized array into a database, where no risk that unknown user changes would be kept as is.

Ideal way would be to extract & modify parts of TPL/PHP files and keeping all around there parts intact.


Something like we done with sidebox moving in "Design Mode" in "advanced" theme, where movable parts are parked with divs and then can be cut/pasted into desired location.


Also if we choose DB storage, then we need to make sure we won't add lots of small tables for that purpose, since already have a lot of tables.

[Alexander Obuhovich]

Another idea about how we can define a layout:

'FormLayout' => Array (

'LayoutA' => Array (

'layout' => Array (

Array ('group_a', 'group_b'),

Array ('group_c', 'empty_group*'),

),

'groups' => Array (

'group_a' => Array (

'header' => Array ('name' => 'subsection', /*'prefix' => 'u',*/ 'title' => 'la_title_GroupA'),

'fields' => Array (

Array ('name' => 'inp_edit_box', /*'prefix' => 'u',*/ 'field' => 'FieldOne'),

Array ('name' => 'inp_edit_box', /*'prefix' => 'u',*/ 'field' => 'FieldTwo'),

Array ('name' => 'inp_edit_box', /*'prefix' => 'u',*/ 'field' => 'FieldThree', 'title' => 'la_fld_CustomFieldTitle'),

),

),

'group_b' => Array (

'header' => Array ('name' => 'subsection', /*'prefix' => 'u',*/ 'title' => 'la_title_GroupB'),

'fields' => Array (

Array ('name' => 'inp_edit_box', /*'prefix' => 'u',*/ 'field' => 'FieldFour'),

Array ('name' => 'inp_edit_box', /*'prefix' => 'u',*/ 'field' => 'FieldFive'),

),

),

'group_c' => Array (

'header' => Array ('name' => 'subsection', /*'prefix' => 'u',*/ 'title' => 'la_title_GroupC'),

'fields' => Array (

Array ('name' => 'inp_edit_box', /*'prefix' => 'u',*/ 'field' => 'FieldFour'),

Array ('name' => 'inp_edit_box', /*'prefix' => 'u',*/ 'field' => 'FieldFive'),

),

),

'empty_group' => Array (

'header' => Array ('name' => 'subsection', /*'prefix' => 'u',*/ 'title' => 'la_title_EmptyGroup'),

'fields' => Array (),

),

),

),

),

This way we define groups of fields and each of groups has corresponding header.

A layout allows to put a groups into desired positions in a table cells during printing. Also if group name has "*" after it's name, then empty rows will be added after it's fields in case if field count in another column in same row is larger then in current column to create nice layout.

[Dmitry A.]

Hi Alex,

I have reread this discussed from the start including your last post. Thanks for latest ideas here. It's interesting and definitely worth continuing the dialog!

At this point, my thoughts are:

1. non-PHP vs. PHP users. I want to outline that today I am less concerned about not gaining non-PHP users than loosing PHP users since if we try to make it for non-PHP users who still can't program any Business Logic in PHP we simply loose all benefits we have for PHP users an in the end we don't offer better/complete solution to neither. If we consider our selves as robust Framework and CMS that can handle any task - we simple can't become a Wordpress type of system even though WP is a great popular blog solution, but it will remain a blog even when people say it's great shipping cart and so on. It's like In-Link back in a day - we could program anything from it - was nice, clean, stable and robust code - no, but it worked.

2. Storing layout in DB. One of the concerns about storing this sort of Layout in the Database is that we won't be able to have this stored in Code Repository (all changes) or if we do we need to create another SQL revision which is not convenient to create, to apply and review. I believe it would faster or equal to update local file and commit it rather then have it in database and have to constantly update SQLs with every new field added and/or changed.

Basically 3 operations will be happening: Change locally in DB, Create SQL Revision, Commit to Repository. Versus 2 if we keep storing it on the file system: Change file and Commit to Repository. Plus hard to read/understand the change log when committed in 1st case.

3. Questions about Benefit of Layouts. Let's say we decide to give it a try and move forward with have Form Layouts stored as files in Array format as you outlined in your last idea. How complex and at the same tile flexible form we can build here? Let's test case it against 3 scenarios to understand the real benifit:

a. Simple form - 1 Column layout with Hints for some fields (all different type, but standard ones). This is probably take up 80% projects

b. Moderate form - 2 Columns layout with Hints, Custom JS, plus some custom field types specific to this template.This is probably take up 15% projects

c. Complex form - 2+ Columns ala RPI add/edit Product field - Hints, Custom JS, Additional Grids, Custom field Types specific to this template. This is probably take up 5% projects

Here we need to rank (1-5, higher is better) the new approach again each of above scenarios to see how we really benefit in:

- Time to Develop and Change

- Flexibility (what can be done)

- Simplicity (straight forward)

I would appreciate your thoughts.

Best regards,

Dmitry A.

Chicago Web Design by Intechnic

[Alexander Obuhovich]

1. yes, I'm also voting for PHP users

2. ok, that makes sense not to store layout in database

3. Here are results

• a) - almost same time, because you need to copy paste field block definitions from somewhere
• b,c) - we can define a block to hold any custom js

Of course at first developers need to figure out how to use new stuff, but in time I believe this would be a real time saver. Also if we move on with kUnitConfig class, then we will be able to add special methods to easy working with layouts.

Having form layouts will:

1. save us time on adding new fields to existing forms and lowers list of breaking form layout;
   
2. will allow to add/remove fields from a forms without actually changing a single template file.

[Dmitry A.]

Thanks for quick reply Alex,

I think we agreed on 1 and 2, so we need to finalize discussion on 3. I am pretty convinced we are going to be in a better shape if we introduce Form Layouts, but still believe we should finish the exercise with Rating (scale from 1 to 5 for each criterion) 3 types of Forms (Simple, Moderate, Complex) that we have against each criterion (Time, Flexibility, Simplicity). This will help us to prove that we are moving in the right direction with this.

Would you please rate them:

NOTE: Replace "current or old" and "new with form layout" with number 1 - 5 (higher is better) so we can rate OLD and NEW way

1. Simple form - 1 Column layout with Hints for some fields (all different type, but standard ones). This is probably take up 80% projects

Time: current or old / new with form layout

Flexibility: current or old / new with form layout

Simplicity: current or old / new with form layout

2. Moderate form - 2 Columns layout with Hints, Custom JS, plus some custom field types specific to this template.This is probably take up 15% projects

Time: current or old / new with form layout

Flexibility: current or old / new with form layout

Simplicity: current or old / new with form layout

3. Complex form - 2+ Columns ala RPI add/edit Product field - Hints, Custom JS, Additional Grids, Custom field Types specific to this template. This is probably take up 5% projects

Time: current or old / new with form layout

Flexibility: current or old / new with form layout

Simplicity: current or old / new with form layout

Thanks!

DA

[Alexander Obuhovich]

1. Simple form - 1 Column layout with Hints for some fields (all different type, but standard ones). This is probably take up 80% projects

Time: 4 / 5

Flexibility: 3 / 5

Simplicity: 5 / 5

2. Moderate form - 2 Columns layout with Hints, Custom JS, plus some custom field types specific to this template.This is probably take up 15% projects

Time: 3 / 5

Flexibility: 3 / 5

Simplicity: 3 / 5

3. Complex form - 2+ Columns ala RPI add/edit Product field - Hints, Custom JS, Additional Grids, Custom field Types specific to this template. This is probably take up 5% projects

Time: 4 / 5

Flexibility: 5 / 4

Simplicity: 4 / 5

On Mon, Dec 24, 2012 at 7:51 AM, Dmitry A. <dand...@gmail.com> wrote:

1. Simple form - 1 Column layout with Hints for some fields (all different type, but standard ones). This is probably take up 80% projects

Time: current or old / new with form layout

Flexibility: current or old / new with form layout

Simplicity: current or old / new with form layout

2. Moderate form - 2 Columns layout with Hints, Custom JS, plus some custom field types specific to this template.This is probably take up 15% projects

Time: current or old / new with form layout

Flexibility: current or old / new with form layout

Simplicity: current or old / new with form layout

3. Complex form - 2+ Columns ala RPI add/edit Product field - Hints, Custom JS, Additional Grids, Custom field Types specific to this template. This is probably take up 5% projects

Time: current or old / new with form layout

Flexibility: current or old / new with form layout

Simplicity: current or old / new with form layout

[Dmitry A.]

Thanks for clarification Alex.

As you can see it's quite helpful to see comparison.

Please create a new task for this in 5.3.0. Also, I wanted to make sure that if needed developer still can use of fashion approach (if needed)

PS. I believe we should make this Test Casing as our standard approach to evaluate usefulness of all Optimization/Improvement tasks that are targeted to replace already existing functionality. 

DA

[Erik Snarski]

Here's an idea how to add a form fields without the complexities that are considered here. In unit config Forms add to each field optional parameters InsertBefore and  InsertAfter, in which you can enter the names of blocks of type DefineElement, which should parse accordingly before the standard form element or after it. All standard form blocks remake so that they understand these options.
 
Adding fields - is the most common modification, so that this method will solve the problem described in the subject in 90% of cases.

[Alexander Obuhovich]

Thanks for suggestion, Erik, but I see several problems with it:

1. we can't have multi-column design
   
2. added field won't be present in case if field, where it's hooked to will be later removed from form
3. actual order of fields inside PHP form definition in unit config isn't clearly noticeable
4. current form definition doesn't include any details how it should be rendered
5. we'll forced to always use one field order with one form

On Wed, Dec 26, 2012 at 7:28 PM, Erik Snarski <sn...@jamajo.lv> wrote:

Here's an idea how to add a form fields without the complexities that are considered here. In unit config Forms add to each field optional parameters InsertBefore and  InsertAfter, in which you can enter the names of blocks of type DefineElement, which should parse accordingly before the standard form element or after it. All standard form blocks remake so that they understand these options.
 
Adding fields - is the most common modification, so that this method will solve the problem described in the subject in 90% of cases.

[Dmitry A.]

Hi Alex and Erik,

Erik, thanks for your input - while you brought up valid issues in terms adding/inserting fields, Alex has valid arguments that suggested solution will limit out flexibility. Erik, let's continue the conversation / brainstorming here to see how we can Improve suggested format for "Form Layout" or what else is missing in it.

Alex, actually, I have another question about our latest version "Form Layout" that we have here. How do we handle:

a. System Presets - are these still going to work the same way?

b. Ability to show/hide field based on DBG status and/or Permissions setting. Remember we can put some IFs around the field to have conditional visibility.

DA

[Alexander Obuhovich]

Right now we have each form element definition wrapped in <inp2:m_if check="{$prefix}_FieldVisible" ...> ... </inp2:m_if> tag. This tag handles field visibility in all cases.

When using form layouts this tag will be applied prior to start drawing a form, because we need to decide how many flexible cells should be added to keep all columns balanced by height.

[Dmitry A.]

Thanks for reply Alex,

I hope we won't be caching it since we can have different layout based on DBG or system presets settings.

DA