On Dec 20, 3:27 am, Thadeus Burgess <thade...@thadeusb.com> wrote: > I can see the logic for how a SmartForm would work, and perhaps as Yarko > suggests I need to sit down and do some flow charts so we can all get an > idea of what I'm thinking, and how this would actually benefit. Lots of > things would benefit from this, from the ability to create better custom > widgets, to assigning custom validation/signals, allowing views that can be > easy, yet powerful and customizable. > > Massimo it would help if you could explain exactly how helpers work, and how > they validate themselves, and how form wraps around helpers, and how sqlform > wraps around form... I would really appreciate it. > > Correct me if I'm wrong. > > It seems that we have Validator classes, and these classes of course, > validate the data. Helper classes can have validators, that when the helper > asks, will validate if the helper has the correct value or not. Helpers can > have children, which consists of other helpers, these are called > components?. Now form is just a helper, that consists of input/textarea/etc > helpers. When form is asked to validate (form.accepts) it recursively > iterates through all of its children helpers, asking them to validate. If > one fails validation, it adds the error to form.errors and form.accepts > returns false. Now sqlform wraps around this, allowing you to specify > database fields, it takes these fields and creates the corresponding helpers > based on data type, or widget if there is one (a widget is just another set > of helpers). sqlform then takes these generated helpers (widgets) and > creates a FORM with them (actually, SQLFORM is a FORM). when sqlform is > asked to validate, it passes the validation on to its FORM part, SQLFORM > then takes the data, and puts it in its correct python type, based on the > data type, and if the form succeeded validation, performs the database > input/output. SQLFORM.factory just creates a DAL reference that does not > link to a database, and passes this along to SQLFORM. When displaying the > form in a view, it just calls its xml() method, which recursively iterates > through all components, asking them to render themselves, which this happens > in class DIV. I think that covers that crazy train :) That pretty much describes it. > > My problem is I don't see a way of creating a smartform, that allows the > separation of logic that will provide the custom interface we all desire, > with using helpers. And the big problem is, since web2py is coupled, I don't > think the this can be solved without the use of helpers either. Not without > having to rewrite a-lot of functionality that already exists, which I > wouldn't want to do. I am starting to think this isn't going to be as simple > as adding a new class, and might require refactoring of how validation is > handled all together, but I'm not sure. i need to sleep on it some more. > What do yall think? We just need a way to decouple the current presentation which can be done using a custom class, but this is neither easy not intuitive. A FORM helper is still the basic block and it includes all the validation, no need to change that. We can widgetize the form fields, now we need to widgetize the form as a whole, its presentation.
On Sun, Dec 20, 2009 at 1:40 AM, hamdy.a.farag <hamdy.a.fa...@inbox.com>wrote: > Now we need SQLFORM to be more customizable, meaning that I can add to > it a field from another table, another field that doesn't belong to > any table and that can be validated upon accepting the form This may fall under MultiSQLFORM as proposed by Maciek Sykulski in http://groups.google.com/group/web2py/browse_thread/thread/7f1dd40a25e4550a# but I have not seen any of the code yet. Denes. -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
