Can you summarize for me what the problem is. This is a long thread and I got lost.
Massimo On Dec 19, 11:46 pm, "hamdy.a.farag" <hamdy.a.fa...@inbox.com> wrote: > Hi There > > @mdipierro , whether SQLFORM was refactored or there will be a new > kind of form , still this's important and needs to be of high > priority > > I work in a team that faced many problems using the current SQLFORM > > 1st if you're work in agile environment , then you don't necessarily > see the whole design of your web application from the 1st time, you > just work and produce , then you refactor and add more changes and so > on > > one of our problems with SQLFORMS is that you may use them with a > table somewhere in the beginnging then you found that > when you need that particular form in another place , you need to add > a field for it . you can add it but still the validation problem is > there > > you may end up not using SQLFORM and always use SQLFORM.factory that > needs more work > > So I'm absolutely with the idea of taking an action towards this > problem . > > thanks > > > No. I django's form.as_p, form.as_ul, form.as_table are not an option > > for web2py. Each of them is a specific solution. I think we are > > looking for a general solution instead. > > > I think this takes two steps: > > > order 0) SMARTFORM = FORM > > order 1) Fields get an .xml() attributes that serializes them using > > the widget > > order 2) move some of the SQLHTML logic into SMARTFORM > > > at that point SQLFORM is just an instance of a SMARTFORM (perhaps the > > default SMARTFORM). > > > On Dec 15, 5:16 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > > > I still do not see how field sets and legends could be determined by a > > > SMARTFORM using the current way web2py HELPERS work. > > > > If you look at ruby on rails, this is why their forms require you to > > > explicitly define your forms. > > > > Django has sort of what I would like, however lacks fieldsets. > > > django's form.as_p, form.as_ul, form.as_table, however for more > > > advanced functionality, django forms provide a similar custom > > > interface to the widgets. > > > > A perfect form solution would actually be a mixture of both, we could > > > have the same as_p, as_ul, as_table. We could have one class > > > (SmartForm) which just defines the widgets, performs the validation, > > > and sets error messages. This would basically be a class that only > > > provides the same interfaces as SQLFORM.custom. Now with a SmartForm > > > class, you create a (FormRenderer) class that will take a SmartForm as > > > an argument (or SmartForm could take a renderer as an argument), and > > > render the form into HTML. > > > > class AsPRenderer(FormRenderer): > > > class AsULRenderer(FormRenderer): > > > class AsTableRenderer(FormRenderer): > > > > We're still left with the difficulty of fieldsets. How do we know what > > > fields break up into which fieldsets ? Passing a list that represents > > > the forms structure is the most logical way I can think of doing this > > > (refer tohttp://pastebin.com/m764d7a39foran example... note the > > > matter list) For this there would need to be a class > > > CustomRenderer(FormRenderer) that takes said list as an argument. > > > (again my first question, I do not know how this could be worked with > > > web2py helpers) > > > > How does this sound? > > > > -Thadeus > > > > On Tue, Dec 15, 2009 at 9:09 AM, mdipierro <mdipie...@cs.depaul.edu> > > > wrote: > > > > There is no reason to make SQLFORM more complex than it is. Why not > > > > move some of the SQLFORM logic into a new object SMARTFORM(?) and > > > > behaves like FORM but accepts Fields as helpers and processes them > > > > like SQLFORM? parhaps SQLFORM could be derived from such a beast. > > > > > Massimo > > > > > On Dec 15, 6:06 am, villas <villa...@gmail.com> wrote: > > > >> @Thadeus > > > >> Thanks for raising this topic. Tables don't seem correct for laying > > > >> out forms any more. So, should we assume that we're all heading in > > > >> the direction of fieldsets? Surely fieldsets should eventually be the > > > >> default. > > > > >> Maybe one way forward to is introduce a new option: > > > >> renderfieldset=False. If true we can get a fieldset and drag our > > > >> forms into the next generation! > > > > >> -David > > > > > -- > > > > > 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 > > > > athttp://groups.google.com/group/web2py?hl=en. > > -- 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.
