new SQLFORM

[mdipierro]

There is a new SQLFORM in trunk. It works as the one before and it is
backward compatible but it allows

form=SQLFORM(...,formstyle='table3cols') # the default but also...
form=SQLFORM(...,formstyle='table2cols')
form=SQLFORM(...,formstyle='divs')
form=SQLFORM(...,formstyle='ul')

I do not think I need to explain but I need to ask you to test them,
in particular when you form contains custom widgets. Please let me
know if you encounter any problem.

Massimo

[mdipierro]

also check the various CSS DIV, LI, TR, TD naming conventions since
once stable it cannot be changed.

[Jose]

maybe this is causing problems when the parameter deletable=True

Error:
File "/usr/home/jose/w2p/gluon/sqlhtml.py", line 748, in __init__
col3.get(self.FIELDKEY_DELETE_RECORD, ''))
TypeError: append() takes exactly one argument (3 given

someone could review

Jose

[Jose]

I sent a patch to Massimo

[mdipierro]

Thank you!

[Thadeus Burgess]

So why formstyle instead of

form.as_div()
or
form.as_ul()

??

-Thadeus

> --
> 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+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
>
>

[Thadeus Burgess]

And why did we lose our classes

".title"
".comment"
".help"

??

-Thadeus

[Thadeus Burgess]

And what about ``ol``, ``p``, ``fieldset`` ?

-Thadeus

[mdipierro]

becase form=SQLFORM() is already a server side representation of the
DOM. It is not an abstract object.
after form=SQLFORM() you are supposed to be able to do
form.element(name)[attribute](value) for example and other DOM
manipulations.

If form were a more abstract object and if its DOM representation were
to be decided later (form.as_div()) you would not be able to
manipulate the DOM. This would 1) break backward compatibility; 2)
break everything that is good about about it.

Massimo

On Apr 1, 3:24 pm, Thadeus Burgess <thade...@thadeusb.com> wrote:
> So why formstyle instead of
>
> form.as_div()
> or
> form.as_ul()
>
> ??
>
> -Thadeus
>

[mdipierro]

Did we ever have them? I do not think I remove everything, or did I?

On Apr 1, 3:26 pm, Thadeus Burgess <thade...@thadeusb.com> wrote:
> And why did we lose our classes
>
> ".title"
> ".comment"
> ".help"
>
> ??
>
> -Thadeus
>

> On Thu, Apr 1, 2010 at 2:24 PM, Thadeus Burgess <thade...@thadeusb.com> wrote:
> > So why formstyle instead of
>
> > form.as_div()
> > or
> > form.as_ul()
>
> > ??
>
> > -Thadeus
>

[mdipierro]

Can you send me a patch?

On Apr 1, 3:27 pm, Thadeus Burgess <thade...@thadeusb.com> wrote:
> And what about  ``ol``, ``p``, ``fieldset`` ?
>
> -Thadeus
>

> On Thu, Apr 1, 2010 at 2:26 PM, Thadeus Burgess <thade...@thadeusb.com> wrote:
> > And why did we lose our classes
>
> > ".title"
> > ".comment"
> > ".help"
>
> > ??
>
> > -Thadeus
>

> > On Thu, Apr 1, 2010 at 2:24 PM, Thadeus Burgess <thade...@thadeusb.com> wrote:
> >> So why formstyle instead of
>
> >> form.as_div()
> >> or
> >> form.as_ul()
>
> >> ??
>
> >> -Thadeus
>

[Russell]

Just a thought...

It occurs to me that, as SQLFORM is a set of fields, wouldn't it be
better if SQLFORMs had their own widget class?

It would allow for customization and, potentially you could then
combine SQLTABLE with SQLFORM into one tidy concept. By this I mean
that SQLTABLE could deliver a set of SQLFORM objects (using a default
read-only widget).

Taking that the next step, for example, you could submit a read-only
row from an SQLTABLE via ajax, toggle the widget to return an edit
form...giving you automatic edit-in-place for the record set.

[mdipierro]

interesting.... I will think about it. Should be possible.