Re: DB_DataObject_FormBuilder questions

Peter Bowyer wrote:

Hi Markus, At 11:35 30/12/2004, Markus Wolff wrote:

you can define a postGenerateForm() method and freeze individual fields there: function postGenerateForm(&$form) {

    $form->freeze(array('field1','field2','field3'));

}

The problem with this (and correct me if I'm wrong) is that this has to go into the DB_DO class (unless I play with global variables) so requires me to have a subclass for 'edit' actions (as opposed to 'add' actions). I'm sure adding this hidden action field to the form is possible, and indeed I have it showing up after modifying preGenerateForm() to add the extra field, but I cannot populate it with a value? Tracking state is needed so I can initialise the correct class on the next page, and show the right fields for the action (otherwise editing goes back to the adding form, with extra fields.

Well, you don't have to put things into the DO itself, you have two other options: 1. Write your own class extending HTML_QuickForm, in which you build the form the way you want it to be depending on the current environment settings. You can then create a method getForm() in your DataObject class, which includes the form class and returns an instance. This will not only separate the form building process from the DataObject, but also speed up things a bit as the field type / rule detection mechanisms as well as the whole form auto-generation that FormBuilder does is being omitted. You can still use the automated insert/update functionality that FormBuilder provides and gradually move from auto-generated forms to individual ones without having to change your frontend code (in other words, you go from rapid prototyping stage into production stage with few effort). 2. You modify the form object in your frontend layer, in other words, when you get the generated form object back from FormBuilder, you can still do stuff with it - such as adding custom rules, freeze single fields or the whole form, remove elements, add elements... everything you can expect to do with a QuickForm object. Please consult the QuickForm docs for more information on how to achieve this. Regarding FormBuilder's scope, please keep in mind that it is intended to be a tool for rapid prototyping. It should be a tool that enables you to quickly fire up an application that works, and also to quickly and easily mold it into a form that is an acceptable base for producing the final application. Once you decide to go into production it should enable you to do this in the most quick and easy way possible, without having to change too much code. It doesn't do anything more than that - and in fact, it shouldn't. If you consider writing a new package that automates creating different views of the same form using sets of permissions, my advice would be not to build this on top of FormBuilder, but on top of QuickForm, simply as a decorator class for existing form objects. This way it will be as generally usable as possible. If you also use LiveUser as backend for the permission sets, only the sky is the limit for what you'll be able to do ;-) CU Markus