back to web2py

7 views
Skip to first unread message

carlo

unread,
Oct 27, 2008, 7:24:59 PM10/27/08
to web2py Web Framework
After some time spent on a Java project which kept me away from my
preferred language, I made a quick refresh of the latest posts.

Found interesting the manual about the T2 plugin but I did not
understand what exactly the purpose of such a plugin shoul be. Someone
could recapitulate?

Reading the T2 manual I also found "It used to be common to create a
<form>...</form> that submits the form variables to a different
page. This is no longer considered good practice."

This reopened an old argue I have with web2py validation because if
you want to benefit of the accepts() feature you must put some form
presentation/helpers in the controller.

Is the Tim Farrell solution as in the "Customizing Forms" thread still
the best? Or something new was added to the web2py cookbook in this
respect?

carlo

mdipierro

unread,
Oct 27, 2008, 9:52:53 PM10/27/08
to web2py Web Framework


On Oct 27, 6:24 pm, carlo <syseng...@gmail.com> wrote:
> After some time spent on a Java project which kept me away from my
> preferred language, I made a quick refresh of the latest posts.
>
> Found interesting the manual about the T2 plugin but I did not
> understand what exactly the purpose of such a plugin shoul be. Someone
> could recapitulate?

a plugin comprise of a set of components (modules, models, views,
controllers and static files) that may be used by more than one app
and act on the global variables (request, response, db, etc.) of the
app that uses the plugin. Examples are CRUD and authentication.

>
> Reading the T2 manual I also found "It used to be common to create a
> <form>...</form> that submits the form variables to a different
> page. This is no longer considered good practice."
>
> This reopened an old argue I have with web2py validation because if
> you want to benefit of the accepts() feature you must put some form
> presentation/helpers in the controller.

Did you look into gluon.sqlhtml.form_factory() which is described in
the book?

> Is the Tim Farrell solution as in the "Customizing Forms" thread still
> the best? Or something new was added to the web2py cookbook in this
> respect?

I think that solves a different problem, inserting hidden fields
(_formkey and _formname) in custom forms. Am I wrong?

billf

unread,
Oct 28, 2008, 2:31:29 AM10/28/08
to web2py Web Framework
Carlo

> > This reopened an old argue I have with web2py validation because if
> > you want to benefit of the accepts() feature you must put some form
> > presentation/helpers in the controller.

With T2, two functions - say "create_widget" and "list_widgets" -
could look as follows:

def create_widget():
return dict(form=t2.create(db.widget)

def list_widgets():
return dict(itemize=t2.itemize(db.widget)

The form creation is still being called by the controller but it is
wrapped in T2 methods. The methods also execute the accepts() method
giving you the validation and db updating which is so great bout
web2py.

I have proposed a patch to Massimo that would allow a custom_view=True/
False argument to be passed to the T2 methods that would cause a dict
to be made available to the view. The dict would be keyed by
fieldname and each item would contain the current form value of the
fieldname and the html component that had been generated by web2py
e.g. an INPUT, SELECT or TEXTAREA. For example, if the dict were
called "latest" then the view could access the value of the field
called name by {{=form.latest.name.value}} or the component for a
dropdown list of countries by {{=form.latest.country.component}} (this
would return a SELECT complete with options and the appropriate option
selected). This allows total flexibility to customize your view in the
the view (except that options would be in the form of a SELECT: of
course, this could be overcome by allowing 'value' to hold a simple
value or a list of option values and which are selected).

With the above patch, creating form html in the controller could be a
convenient option that could be switched off if not required.
Personally, I think that as web2py gains popularity it will be taken
up more by graphic orientated people (because of its simplicity). If
this is the case, the automatic html generation, whilst useful in
developing and testing, will be rarely used in the final application
generation and the primary interface between data and view should be
html-less.

Perhaps there would eventually be 3 options - all controlled in the
view - apologies if the syntax is rubbish:
- take the object and output as standard web2py html (the current
method but controlled by the view), e.g. {{=form(default=True))}} or
{{=form_helper({{=form}})}}?
- get the value of a field and plug into hand-rolled html, e.g. <INPUT
name="description" value="{{=form.description}}"/>
- use a helper method, e.g. {{=select_helper(={{form.country}})}}

Sorry - got a bit off the topic there.

carlo

unread,
Oct 28, 2008, 7:56:30 AM10/28/08
to web2py Web Framework
> a plugin comprise of a set of components (modules, models, views,
> controllers and static files) that may be used by more than one app
> and act on the global variables (request, response, db, etc.) of the
> app that uses the plugin. Examples are CRUD and authentication.

thank you.


> > Reading the T2 manual I also found "It used to be common to create a
> > <form>...</form> that submits the form variables to a different
> > page. This is no longer considered good practice."
> > This reopened an old argue I have with web2py validation because if
> > you want to benefit of the accepts() feature you must put some form
> > presentation/helpers in the controller.

> Did you look into gluon.sqlhtml.form_factory() which is described in
> the book?

mmh..which book please?

> > Is the Tim Farrell solution as in the "Customizing Forms" thread still
> > the best? Or something new was added to the web2py cookbook in this
> > respect?
> I think that solves a different problem, inserting hidden fields
> (_formkey and _formname) in custom forms. Am I wrong?

no it exactly addressed this great (imho) problem, in Tim's words:

"I crossed this bridge a few weeks ago. I, like you, don't dig the
whole
presentation logic in the controller. However, it is still reasonable
to build a "form" in the controller for logical data-handling
purposes. "

Timothy Farrell

unread,
Oct 28, 2008, 9:23:15 AM10/28/08
to web...@googlegroups.com


carlo wrote:

<snip />

Did you look into gluon.sqlhtml.form_factory() which is described in
the book?
    
mmh..which book please?

  
THE web2py book:
http://www.amazon.com/Web2Py-Manual-DiPierro/dp/0470432322
even though you can get a DRMed eBook of it here:
http://store.vitalsource.com/show/9780470432327
many of us are still waiting on the true PDF version.


  
Is the Tim Farrell solution as in the "Customizing Forms" thread still
the best? Or something new was added to the web2py cookbook in this
respect?
      
I think that solves a different problem, inserting hidden fields
(_formkey and _formname) in custom forms. Am I wrong?
    
no it exactly addressed this great (imho) problem, in Tim's words:

"I crossed this bridge a few weeks ago.  I, like you, don't dig the
whole
presentation logic in the controller.  However, it is still reasonable
to build a "form" in the controller for logical data-handling
purposes.  "
  
The "Tim Farrell Solution"...I'm flattered. =)

I agree with billf...
...creating form html in the controller could be a
convenient option that could be switched off if not required.
  
In the long run, I would prefer "switched ON" if required.  But that would break API, so it will have to wait until web3py(TM).

Personally, I think that as web2py gains popularity it will be taken
up more by graphic orientated people (because of its simplicity).  If
this is the case, the automatic html generation, whilst useful in
developing and testing, will be rarely used in the final application
generation and the primary interface between data and view should be
html-less.
Well said.

tfarrell.vcf

carlo

unread,
Oct 28, 2008, 10:03:21 AM10/28/08
to web2py Web Framework
dear billf and Tim,

you look advanced about tackling this issue and I call for your
support.

As I do not have yet much confidence with T2 plugin I am not sure I
grasped what billf suggested.
Billf, do you mind posting an example form with your method?

My intention was always to have my forms defined entirely in the view
(no widgets just html or sometimes html helpers) and Tim's solution
looks addressing this issue (apart from some logic in the controller)
though I did not test it yet extensively. My procedure was to send my
form to a different controller where validation was accomplished by
calling some custom functions which use the built-in validator class.
Of course this breaks the auto submit paradigma that I agree should be
a better practice.

Your suggestions are welcome,

carlo

Timothy Farrell

unread,
Oct 28, 2008, 10:16:21 AM10/28/08
to web...@googlegroups.com
Carlo,

I haven't eaten the T2 candy yet either.

Been there, done that.  I'd encourage you not to submit to a different function.  It's tempting for me because it makes for smaller functions, but I learned the hard way that this is not the way to go.  I started out with my login form that submitted to an "auth" function.  It was a nightmare trying to get the user where they needed to be without creating infinite loops.  I eventually pulled the session validation code out to a module while moving the authentication code into the "login" function (which previously only displayed the login page).  Now it's clean and maintainable and the chance for infinite loops is 0.

-tim
tfarrell.vcf

carlo

unread,
Oct 28, 2008, 10:39:27 AM10/28/08
to web2py Web Framework
Thank you Tim,

are you still using your previously posted trick to have forms mostly
in the view? Any problem with that?

carlo
>  tfarrell.vcf
> < 1KViewDownload

Timothy Farrell

unread,
Oct 28, 2008, 10:43:43 AM10/28/08
to web...@googlegroups.com
You're welcome.

I am still using it, though it hasn't gone into production use yet.  It has worked normally however throughout the development phase.  I don't foresee any issues with it.  I'll let you know if I come up with anything.
tfarrell.vcf

carlo

unread,
Oct 28, 2008, 11:43:45 AM10/28/08
to web2py Web Framework
Just to say I tried your code and It worked fine.
I also tried passing some data from controller and using html helpers
(that I find handy) in view like:

# in controller
rows_clients=db().select(db.clients.ALL)
....
return dict(rows_clients=rows_clients)

# in view

<form>
.......
<div>

{{ t=TABLE(TR('Client:',SELECT(*[OPTION(rows_clients[i]
['name'],_value=str(rows_clients[i]['id']))\
for i in range(len(rows_clients))]))) }}
{{=t}}

</div>
...
</form>

and everything looks ok.

To me your code is the workaround I was looking for months, thank you

carlo
>  tfarrell.vcf
> < 1KViewDownload

billf

unread,
Oct 28, 2008, 1:42:36 PM10/28/08
to web2py Web Framework
Carlo

The T2 methods like create() and update() bundle the SQLFORM and
accepts() and add some nice things like automatically updating stamp
columns, e.g. created_by, modified_on, making nice short controller
actions. However, on the downside, html related code is now in the T2
methods as well as SQLFORM and FORM.

I have proposed an approach in another thread and, for space reasons,
written up an example at http://www.wellbehavedsystems.co.uk/web2py/examples/custom_forms.html.
Basically, this approach adds methods and overrides a method on FORM
and DIV to get the FORM to give access to form values and components
by fieldname (as mentioned in my first post above). This example was
a first attempt that concentrated on the create and update forms.

I have got a bit bolder now and I am looking develop html-less T2
methods, and html-less versions of SQLFORM and FORM. This is still a
work in progress and when working will be humbly submitted to y'all
and Mr M for consideration.

mdipierro

unread,
Oct 28, 2008, 1:51:37 PM10/28/08
to web2py Web Framework
keep us posted

On Oct 28, 12:42 pm, billf <billferr...@blueyonder.co.uk> wrote:
> Carlo
>
> The T2 methods like create() and update() bundle the SQLFORM and
> accepts() and add some nice things like automatically updating stamp
> columns, e.g. created_by, modified_on, making nice short controller
> actions. However, on the downside, html related code is now in the T2
> methods as well as SQLFORM and FORM.
>
> I have proposed an approach in another thread and, for space reasons,
> written up an example athttp://www.wellbehavedsystems.co.uk/web2py/examples/custom_forms.html.

carlo

unread,
Oct 28, 2008, 5:27:19 PM10/28/08
to web2py Web Framework
much clearer now thank you.

Definitely T2 methods like create() and update() can become
interesting to me only if your efforts to code a html-less version of
them will get to success.

carlo

On 28 Ott, 18:42, billf <billferr...@blueyonder.co.uk> wrote:
> Carlo
>
> The T2 methods like create() and update() bundle the SQLFORM and
> accepts() and add some nice things like automatically updating stamp
> columns, e.g. created_by, modified_on, making nice short controller
> actions.  However, on the downside, html related code is now in the T2
> methods as well as SQLFORM and FORM.
>
> I have proposed an approach in another thread and, for space reasons,
> written up an example athttp://www.wellbehavedsystems.co.uk/web2py/examples/custom_forms.html.

mdipierro

unread,
Oct 28, 2008, 5:48:47 PM10/28/08
to web2py Web Framework
I am not sure why you say there is any need to change T2 to use custom
forms with T2.

For example:

#in model

db.define_table('dog',SQLField('name',default=''))

def custom(table):
import uuid
formkey=session['_formkey[%s]' % table]=str(uuid.uuid4())
return DIV(INPUT(_name='_formname',_value=str(table)),
INPUT(_name='_formkey',_value=formkey)))

#in controller

def index(): return dict(form=t2.create(db.dog))

#in views

<form>
{{=custom(db.dog)}}
<input name="name" value="{{=form.vars.name or
db.dog.name.default}}" />
<input type="submit">
</form>

I guess custom can be made a method of the form itself. Bill sent me a
patch to do this. But this will do for now.

Massimo

billf

unread,
Oct 29, 2008, 2:14:51 AM10/29/08
to web2py Web Framework
Massimo

I think there are a few issues raised by your suggestion - excuse my
ramblings:

1) If I knew as much about web2py as you I would have thought of your
solution and not dug around as much :-)
2) I'm not sure adding html to the model satisfies everyone.
3) Dealing with fields that have options requires a different (or just
more complicated) approach.
4) For the longer term, the view really needs concise helpers aot
referring to both form.vars and db.table.field.default all the time -
where would they reside?
5) For backwards compatibility, your custom() needs to handle other
things like additional hidden fields.
6) I think that my interest/requirement has moved beyond custom forms
to custom views so what should the t2 methods search(), itemize() and
display() be returning (if not the current html)?
7) Personally, I don't think that the accepts() and rec_accepts()
methods should reside in what are basically html objects (SQLFORM,
DIV, INPUT). There is an argument, I don't know how strong, that if
one considers REST, there may never have been a form - the controller
could just receive a PUT, POST or DELETE that needs to be validated
and acted upon.

To be honest, I'm not sure where I think the validation and db update
logic should reside. A quick list of random thoughts:
- in the model, simply add methods
- in the model - create a base "model" class that all application
models extend
- should a model be tied to SQL (this could be a terrible, time-
wasting distraction)
- in a resource - create a resource class that would usually wrap a
record or a list of resources but could wrap other things like a non-
html form (e.g. the bones of a search form) - in some ways a
replacement for the way DIV is used currently - different kinds of
resources know how to validate and persist themselves, return their
attributes and, if required, render themselves in html, xml or
whatever - could fit in nicely with REST

This is all just brainstorming - I'd love to read other peoples' views
(including "not important", "leave well alone" and "shut up this is
really boring").
> ...
>
> read more »

mdipierro

unread,
Oct 29, 2008, 9:02:50 AM10/29/08
to web2py Web Framework
I mostly agree with you, that is why some version of "custom" + your
patch will be in the next version.

Massimo
> ...
>
> read more »
Reply all
Reply to author
Forward
0 new messages