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!
Main | My View | View Issues | Change Log | Roadmap | Docs | Wiki | Repositories
  

Relationship Graph [ View Issue ] [ Dependency Graph ]
related to child of duplicate of

Viewing Issue Simple Details
ID 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  
Assigned To
Priority normal Resolution open  
Status active      
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

Main | My View | View Issues | Change Log | Roadmap | Docs | Wiki | Repositories
  

Web Development by Intechnic
In-Portal Open Source CMS
In-Portal Open Source CMS
Copyright © 2000 - 2009 MantisBT Group

Powered by Mantis Bugtracker