I need some help then. I do not see any way this is possible using the
current system of helpers and how data is validated by these helpers.
-Thadeus
On Fri, Dec 18, 2009 at 12:21 PM, Yarko Tymciurak <
resultsinsoftw...@gmail.com> wrote:
> On Dec 15, 6:09 pm, Thadeus Burgess <thade...@thadeusb.com> wrote:
> > The real problem is the cohesion between Models and Views within the
> > "internal" aspects of web2py. SQLFORM is way too cohesive between
> > validation and rendering.
>
> I think the term that describes this is "coupling" - there is design
> coupling between validation, and rendering, which couples model and
> view aspects.
>
> This is an important topic for web2py - not just from the immediate
> developer perspective (and both Denes and Thadeus, I think, have come
> on some convergent view) - but from a generalization point of view:
> Coupling is natural in some cases, and can be useful to simplify
> behavior and setup.... In this case, what is coming up is that it is
> standing in the way of generalization (e.g. easily changing layout).
>
> I would suggest at this point to layout a diagram, and attempt to
> state the problem these classes are trying to solve - and then test
> the appropriate generality.
>
> E.g. "this works for changing HTML layout; does it work for Ajax
> equally well? How does it affect CSS layout control? Will it
> facilitate a site/application designer in moving from an HTML/CSS
> prototype to, say, a flash/flex UI solution? To alternate layouts for
> smart mobile devices (there are quite a number of web-capable devices
> now, e.g. iPhone, Droid, etc.)
>
> These questions will start to flush out what degrees of freedom are
> needed, and help refactor for most useful decoupling.
>
> Some general use cases will help also. Right now, web2py seems to be
> implicitly built around rapid-prototyping based on data layout (which
> is where all the validation and form defaults come to play - lets not
> break that!). What this, in effect, is asking for is rapid
> prototyping from the presentation end - if both of these are in place,
> this will be doubly useful as prototypes can evolve from alternately
> both directions.
>
> - Yarko
>
> > In my opinion, this is why I suggested separate classes, one for the form
> > model, and another for the form rendering(view).
> >
> > You solution, though works, creates an even bigger mess, since view
> > code would then also, be located in sql.py.
> >
> > -Thadeus
> >
> >
> >
> > On Tue, Dec 15, 2009 at 5:52 PM, Thadeus Burgess <thade...@thadeusb.com>
> wrote:
> > > I wouldn't be so quick to dismiss as_p as_ul and as_table. As they
> > > offer pre-defined templates.
> >
> > > Also, I am quickly playing aroudn with your suggestion. I added
> > > .forform() (that just returns self.widget(self, self.default) to field
> > > objects, and I am using FORM.
> >
> > > The problem with this approach is it still requires the developer to
> > > declare simple things, such as labels and submit buttons...
> >
> > > The following actually renders perfectly, and validates, however,
> > > requires the developer to define labels, submit buttons and such.
> >
> > > form = FORM(
> > > FIELDSET(LEGEND("Personal Information"),
> > > P(db.test.first_name.forform()),
> > > P(db.test.last_name.forform()),
> > > ),
> > > FIELDSET(LEGEND("Login Information"),
> > > P(db.test.username.forform()),
> > > P(db.test.password.forform()),
> > > ),
> > > FIELDSET(
> > > INPUT(_type="submit", _value="submit"),
> > > )
> > > )
> >
> > > Is this what you ment by a "generic" solution?
> >
> > > -Thadeus
> >
> > > On Tue, Dec 15, 2009 at 5:22 PM, mdipierro <mdipie...@cs.depaul.edu>
> wrote:
> > >> 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<web2py%2bunsubscr...@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<web2py%2bunsubscr...@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<web2py%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://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.
