Re: New package: DB_DataObject_FormBuilder

Doesn't $qf->process() return the return value of the user function? It looks like it does to me. function process($callback, $mergeFiles = true) {

       ..snip..
       return call_user_func($callback, $values);

} // end func process You could return an array of validation errors, or just false to signal that there were errors and expect application code to pick them up by calling validate on the orignal DO again, though that means two calls to validate. Or, go ahead and store validation errors in the DO or formbuilder, and have the user pick them up there, i'm not sure what's best, as I don't have time to look at the code now.. work's killing me ;) -Ron

That's the quickform validation. Before actually inserting of updating, it would be helpful if data_object validation were run. There's an actual DB_DataObject->validate() call that has nothing to do with QuickForm->validate(). See the DataObjects documentation. Let me know if this still doesn't make sense ;)

Ah, now I get it... and now it makes sense, of course ;-) The question remains, how to properly integrate it. I think it would make sense to somehow return the validation errors (if any) to the user. If we integrate validate() into processForm(), however, you can´t return any data from that method directly, or you won´t be able to use it with HTML_QuickForm::process(), which doesn´t return the results of the callback method to the user. It seems our best bet would be to make a) a public validate() method in FormBuilder that can be called seperately if needed and will return the results directly, b) an additional property that determines wheter DataObject::validate() is to be called automatically by processForm() and c) make yet another property that will store the last validation results - in case you were using QuickForm´s process() and have no other means to get to that data. Does that sound alright? Regards, Markus