I will have to go over the changes in html.py but:
1) I also agree with Bill. The point here was really the MVC
separation as he calls it in a separate post. Plus a leaner version of
the generated HTML. I have no idea how hard would it be to re-position
a TD in a complex form just using CSS.
2) Many debatable positions can be taken here too. Should labels be
considered part of the form data or not? Where would they fit better?
<add your own here >
I know the info is available from other sources but I think it is more
elegant to have it all come from one source: the form itself.
2b) A separate issue here is the use of display only fields versus the
current all input. The presentation value becomes dependent on its
final use (input or display), and the existence of: record, reference,
requires and widgets for each. Again, the objective would be to have
it all available from one source: the form.
3) Errors have been always available from the form object, the way it
should be IMO. Here I want to hear about other nice and elegant ways
to handle the errors. Maybe we can have one in the improved version if
the opinions are not too divergent.
4) I have cascades and autocompletes in my current forms and I posted
how I did it, but the setup is a little convoluted so I would like to
automate it. They use jQuery plugins. Other special field types that
can be added here? Maybe make them into web2py plugins?.
It is all a work in progress...
On Nov 10, 2:01 am, mdipierro <[EMAIL PROTECTED]> 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's patch in 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
