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
-~----------~----~----~----~------~----~------~--~---
