| Previous · Next | |
| User | Message |
|
arjan
|
Date: 3/8/2011 5:46 am · Subject: The future of templating forms: what about this as a default field_loop · Rating: -1
Dear all,Note for template-list: please reply to the dev-list to keep the discussion in one place. Today Rogier and I talked about the best general way to make form fields available in a template. Below is our preliminary conclusion. 1. Every form is defined in the template by a field_loop. 2. Every field is available by name and all attributes of a field are available seperately. This makes it possible for a templater to create a custom formfield. He can choose between a multiple select list and a checkbox list for example. He can create every tag to his own liking. Two practical examples for the use could be: A. The ideal way to template checkbox lists or radiobutton lists is to put them in a fieldset where the variable tmpl_var label is the legend. Currently there's no way of checking whether tmpl_var label should be in a label tag or legend tag. In the proposition below the templater can check for an options loop. B. For every field the label can be explicitly associated via the for-attribute in this proposition. Currently it is impossible to use the for-attribute. 3. A defaultFieldType is specified (hidden/password/textarea), so every form can have a default template in which all form fields are iterated and displayed in the same way it is done in templates right now. The practical use for this is to be able to make general default templates that always contain all form fields even if it is not known in advance what fields will be available in the form. 4. Optionally the whole could be wrapped into a fieldset_loop. (see the second definition) What are the thoughts about this? In my view, this is a best of both worlds implementation. General templates on the one hand, but with the possibility to make specific templates in specific implementations. p { margin-bottom: 0.21cm; } field_loop =>
[ { Or the whole could be wrapped in a fieldset_loop: p { margin-bottom: 0.21cm; } fieldset_loop [ { isFieldsetName => 1/0, name => fieldsetName fieldsetId => abc, legend => abc, field_loop => [ { etc. Kind regards, Arjan Widlak -- Setting Standards, a a Delft University of Technology and United Knowledge simulation exercise on strategy and cooperation in standardization, http://www.setting-standards.com United Knowledge, internet voor de publieke sector Keizersgracht 74 1015 CT Amsterdam T +31 (0)20 52 18 300 F +31 (0)20 52 18 301 bureau@unitedknowledge.nl http://www.unitedknowledge.nl M +31 (0)6 2427 1444 E arjan@unitedknowledge.nl Bezoek onze site op: http://www.unitedknowledge.nl Of bekijk een van onze projecten: http://www.handhavingsportaal.nl/ http://www.setting-standards.com/ http://www.lomcongres.nl/ http://www.clubvanmaarssen.org/ |
| Back to Top |
Rate [ | ]
|
|
preaction
|
Date: 3/8/2011 12:49 pm · Subject: Re: The future of templating forms: what about this as a default field_loop · Rating: -1
This is almost how WebGUI::FormBuilder does it: { P is a "prefix", which is set by the programmer in case there are more than one form in the page (usually, P will be 'form'). Looking back at it, the only limitations are that fields inside of fieldsets and tabsets are not available by name from the outer set of variables, and there's no simple loop of all object types (fields, fieldsets, and tabsets) so you could not really replicate the form's HTML exactly using template variables. These can both certainly be added pretty easily. There are more variables than what I listed, mostly individual accessors for every little thing possible. It's a good thing Paul added the template preview stuff, because the massive number of form variables is getting a little out of hand. Hopefully as we remove support for ancient and crufty template systems we can come up with better ways of making the HTML fields from the DB field definitions. |
| Back to Top |
Rate [ | ]
|
