In-Portal Issue Tracker

Welcome to the In-Portal Open Source CMS Issue Tracker! This is a central management / tracking tool for all types of tasks / issues / bugs for the In-Portal Project. Before reporting any issues, please make sure to read the Guide into Issue Tracker and How to Properly Test and Report Bugs!

Viewing Issue Simple Details [ Jump to Notes ] [ Wiki ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Type

Reproducibility

Date Submitted

Last Update

0000270

[In-Portal CMS] Admin Interfaces

feature request

N/A

2009-09-04 14:55

2011-09-26 05:05

Reporter

alex

View Status

public

Project Name

In-Portal CMS

Assigned To

Developer

Priority

normal

Resolution

open

Fixed in Version

Status

active

Product Version

5.1.0

Target Version

Icebox

Time Estimate

No estimate

Summary

0000270: "Form Configuration" for Add/Edit in Admin Console

Description

Currently each editing template in Administrative Console consists of several parts:

1. header - shows template header and record name, that being edited;
2. toolbar - common buttons, that allows to manipulate record being edited;
3. form fields - set of blocks, that shows controls used for data editing on given form.

There nothing special about header and toolbar, because they are already highly flexible and meet most and less common needs, but there is something not too flexible about form fields. Form fields order and grouping into subsections is hardcoded and can't be changed without directly editing given template. For now we only have option for dynamically hiding each of the fields and in case if all subsection fields are hidden, then subsection will be hidden automatically.

Idea is to define form (or several forms) inside unit config and tell what form fields should be displayed, where they should be displayed inside the layout (see task 0000269) that is used on that form, how they should be grouped into subsections, tell the order of fields and what validator class should be used to validate data from this form (see task 0000271). In mentioned below example there is approximate idea about how form configuration could be made.

$config = Array (
    'Forms' => Array (
        'Default' => Array (
            'Validator' => 'kValidator',
            'ValidationRules' => Array (
                'SampleField' => Array ('required' => 1, 'max_len' => 255),
                'Discount' => Array ('min_value_inc' => 0, 'max_value_inc' => 100),
            ),
            'LayoutName' => 'TwoColumns',
            'LayoutData' => Array (
                'cell_one' => Array (
                    'la_subsection_General' => Array (
                        'Priority' => 1,
                        'Fields' => Array (
                            'SampleField' => Array ('name' => 'inp_edit_box', 'title' => 'la_fld_SampleField'),
                            'OptionField' => Array ('name' => 'inp_edit_options', 'title' => 'la_fld_OptionField', 'has_empty' => 1),
                        ),
                    ),
                    'la_subsection_Discount' => Array (
                        'Priority' => 2,
                        'Fields' => Array (
                            'Discount' => Array ('name' => 'inp_edit_box', 'title' => 'la_fld_Discount', 'style' => 'width: 50px;'),
                            'DiscountType' => Array ('name' => 'inp_edit_radio', 'title' => 'la_fld_DiscountType'),
                        ),
                    ),
                ),
                'cell_two' => Array (
                ),
            ),
        ),
    ),
);

Example mentioned above is a hard piece, that's why it will be described more thoroughly. In this example there is one form named "Default". Later this form name will be used on editing template to show this form. There are four main parameters in each form definition: Validator (validator class, that should be used to validate data, that will be submitted from this form), ValidationRules (field-specific validation rules if any, for fields, displayed on this form), LayoutName (layout name, used to display form on editing template), LayoutData (form field placement inside the layout). Each key of "LayoutData" array is cell name inside layout (see task 0000269) and it's content are fields, that should be shown in that cell. Field-specific validation rules, specified in ValidationRules option will be passed to validator class (see task 0000271), specified in "Validator" option of form and will be used to validate given form field. Each cell data consists of subsection names (as keys) and form fields inside each subsection. Each subsection has priority ("Priority" key) among other subsections in this cell and form fields ("Fields" key), that will be shown in this subsection. Keys in "Fields" array are field names, to be shown. All options will be passed directly to "kApplication::ParseBlock" method to form individual form field HTML code.

Form-based data validation will allow to create different forms for editing same data and each of forms can have different validation logic form same fields. This aspect will be detailed in 0000271 task.

Additional Information

Issue History
Date Modified	Username	Field	Change
2011-09-26 05:05	alex	Target Version	5.2.0 => Icebox
2011-07-08 10:57	alex	Target Version	Icebox => 5.2.0
2010-08-31 14:27	alex	version	=> 5.1.0
2009-09-05 07:10	alex	Description Updated	View Revisions
2009-09-04 17:23	Dmitry	Summary	"Form Configurattion" for Add/Edit in Admin Console => "Form Configuration" for Add/Edit in Admin Console
2009-09-04 17:17	Dmitry	Summary	Administrative console form configuration => "Form Configurattion" for Add/Edit in Admin Console
2009-09-04 17:17	Dmitry	Description Updated	View Revisions
2009-09-04 17:11	Dmitry	Target Version	=> Icebox
2009-09-04 15:30	alex	Relationship added	related to 0000271
2009-09-04 15:29	alex	Description Updated	View Revisions
2009-09-04 14:56	alex	Relationship added	related to 0000269
2009-09-04 14:55	alex	New Issue