Forms Customization

[GoogleCodeExporter]

Bungeni presently provides content entry forms and views for its content types. 
These forms may require customization to meet local parliamentary requirements. 
The current architecture of the forms does not allow it to be customized in 
certain aspects. This issue attempts to document these deficiencies and also 
document the customization requirements which the form framework needs to 
fulfill.
A general summary of the customization requirement is as follows -- It must be 
possible to relatively easily customize the forms for the content types in 
bungeni -- from the following aspects :
  -- Enable / Disable fields in a content-type form globally
  -- Enable / Disable fields in a content-type form based on role
  -- Change the order of presentation of the fields
  -- Separate the customization aspect from the source code 

I have attempted to provide an overview of the current form architecture here :

<http://code.google.com/p/bungeni-portal/wiki/Framework_Internals>

Requirement 1 -  Enable / Disable view/edit fields in a content-type form 
globally

In the schema (see bungeni.models/schema.py) we try to define as many fields as 
possible for a content type. There are cases where all of them may not be 
relevant for a parliament -- and hence a requirement to "hide" a field from the 
user interface and the views.  Right now the way to do it is to remove the 
field from the schema -- but this is not practically feasible from a 
customization point of view as there is other code referring to the removed 
field -- and anyhow parliamentary level customization should not involve schema 
changes for individual parliaments. Ideally it must be possible to disable the 
display of the field in the form ui.

Requirement 2 - Enable / Disable view/edit fields in a content-type form based 
on role

Enable / Disable display of view/edit fields on a form based on a role filter. 
Note that the machinery for this seems to be there (see the view_permission, 
edit_permission attributes in the ore.alchemist.model.Field class) -- but its 
not clear as to how to use it / or if it works at all.

Requirement 3 -  Change the order of the presentation of the fields

The order of the fields is currently defined by the order of the fields in the 
model descriptor. Since the model descriptor is a core source code file -- it 
is not feasible to change it for  individual parliaments as it would result in 
forking of source. The requirement is to allow customization of field order for 
individual parliaments.

Requirement 4 - Separate the customization aspect from the source code 

Any customization configuration / aspect must be clearly differentiated from 
the source code. preferably in its own folder within the main buildout folder.

Some important things to consider --

--- In the future we might want to provide a user interface for the 
customizations listed above. This might impact upon how we structure the 
customization aspect. e.g. the form descriptors are in a python file …perhaps 
moving it to a xml representation makes it easier to build customization user 
interfaces on top of it ? Any other approaches should also be discussed.

-- Mandatory / Non-mandatory fields -- not EVERY field in a form can be open 
for enable / disable customization -- some fields are mandatory as they are the 
bare minimum data to describe the object. (e,,g, "moved by" field in Question 
is mandatory and cannot be disabled …). We probably need to define this for 
every content type.

-- The use of alchemist.catalyst results in auto-generation of form classes and 
interfaces. Perhaps auto-generation is not be the best approach, an alternative 
is to look at manually generated forms -- but this will require manualy 
creating the plumbing automatically added in by catalyst. If this is the case a 
completed conversion of an existing content type (e.g. Question ) as 
non-catalyzed content type is required.

Original issue reported on code.google.com by ashok.ha...@gmail.com on 31 Jul 2010 at 9:21

[GoogleCodeExporter]

This is currently being implemented as follows -- 

<http://code.google.com/p/bungeni-portal/wiki/DevFormLocalization>

Original comment by ashok.ha...@gmail.com on 16 Feb 2011 at 11:33

[GoogleCodeExporter]

This has been implemented

Original comment by ashok.ha...@gmail.com on 1 Dec 2011 at 11:33

• Changed state: Closed