This looks like what I need: custom forms with fields that can tie
into model and database, including validation,etc.
But this modified version of "Bill's patch" hasn't yet made it into
production yet (1.54), is that correct?
-Peter
On Nov 10, 8:01 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> Attention!!! I posted in trunk a complete rewrite of gluon/html.py
>
> In my tests it does not break anything but please try it and let me
> know if it break something before I post an new web2py version.
>
> The reason for the rewrite is mainly to make form processing twice as
> fast and the code more readable, but also to include Bill'spatchin a
> more elegant way. The new html is 5% smaller than the previous one.
>
> About the comments below:
>
> 1) I agree with Bill
> 2) one can do db.table[fieldname].label and get the label (*)
> 3) I agree. One can do {{if form.errors.has_key(fieldname):}}
> {{=form.errors[fieldname}}{{pass}} (*)
> 4) Now you can do a custom form like
>
> db.define_table('person',SQLField('name'))
>
> def index():
> form=SQLFORM(db.person)
> if form.accepts(request.vars,session)
> return dict(form=form)
>
> {{if form.errors:}}{{=form.errors}}{{pass}}
> <form>
> <input type="text" name='name' value="{{=form.values.name}}" />
> <input type="submit" />
> {{=form.hidden_fields()}} <!--you need this to prevent double
> submission and allow multiple forms //-->
> </form>
>
> Please let me know if it works. I am hoping to post a new release
> before my talk at pyworks2008.
>
> Massimo
>
> On Nov 10, 12:06 am, billf <billferr...@blueyonder.co.uk> wrote:
>
> > 1) tables over something else: it does seem to be a subject of great
> > discussion that people get very energised about. But I guess that if
> > you take out tables then someone else will object :-) Isn't the idea
> > of custom forms that if you want labels you code your own view?
>
> > 2) labels: personally I don't think the specification of labels fits
> > elegantly in the model or the controller but I recognise the need to
> > put them somewhere if you want to avoid duplicating them in multiple
> > views. Ideally, they could be defined in an application view, e.g.
> > layout.html, and referenced by views that extend that - is that
> > possible? I would interested to hear other people's views.
>
> > 3) I think custom error handling is part of custom views: the
> > developer has access to the field value and error messages so can do
> > what they want.
>
> > 4) Sounds great: once spec'd it will be interesting to see if these
> > are core web2py or not.
>
> > My original proposal grew out of my own requirements to convert an
> > existing app to web2py: I just wanted access to the latest values and/
> > or html component (to handle SELECTs). As such the proposal works
> > fine.
>
> > However, since then, I have got interested in (IMHO) cleaning up the
> > web2py approach to MVC. By that I mean, no view stuff in the model
> > (e.g. labels) or the controller (passing labels to SQLFORM) and
> > separating db updates from html creation (both in SQLFORM). So I have
> > been developing some ideas that are probably at the point where group
> > comment would be really useful. I would post them as a blueprint but
> > this forum seems to be the place to get feedback so I am going to
> > create a new thread.
>
> > On Nov 10, 4:39 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > fine with everything but what's the problem of table in form. You can
> > > use CSS to completely override the table layout and more the TD
> > > anywhere you like on the screen as if they were a DIV. Am I wrong?
>
> > > Massimo
>
> > > On Nov 9, 10:30 pm, DenesL <denes1...@yahoo.ca> wrote:
>
> > > > Regarding this subject, I have been running some tests as time
> > > > permits.
> > > > May I suggest the following (which I might have mentioned before):
>
> > > > 1) The form needs to be more CSS friendly (following the MVC pattern).
> > > > This means no tables.
> > > > In my tests I have been able to trim the fields to: <label...>
> > > > +<input...>+comment+<br/>
> > > > and with very simple CSS make the form look like the current one.
> > > > More complex CSS could be used to position each element individually
> > > > if desired.
>
> > > > 2) For each field passed to the form its label and its value must be
> > > > accessible in the view via a statement similar to the one mentioned
> > > > above: {{=form.latest.field}}, mine look like {{=form.label.field}}
> > > > and {{=form.value.field}}. Labels are required for translation
> > > > purposes. Some field values, like those of select type fields, require
> > > > special consideration; specially when the fields can be converted to
> > > > display only (e.g. using DIV instead of INPUT).
>
> > > > 3) Custom forms also need custom form error handling. My solution so
> > > > far is to use a small JS to change the background color of the fields
> > > > in error and change the title attribute to hold the error, so hovering
> > > > a field in error displays the error message. But this is probably a
> > > > matter of personal preference. Same as replacing the comment with an
> > > > image of a question mark that opens the text when requested without
> > > > cluttering the form.
>
> > > > 4) In the future I would like to integrate the automatic creation of
> > > > cascaded fields and autocompletes if possible.
>
> > > > I could be leaving something out but things tend to come out on the
> > > > ensuing discussion.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@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
-~----------~----~----~----~------~----~------~--~---
