web2py and self-submission/postbacks - a newcomer asks

[Graham Ranson]

I'm new to python and web2py...I have a small, but non-trivial, web
application and was looking at the various python web frameworks and decided
to look more closely at web2py and a couple of others and to write a couple
of small example applications to see how they work...

I've had a quick read of the web2py book but I was a little surprised by the
emphasis on self-submission/postbacks, it's not a technique that I would
choose myself. I was wondering whether there was anything in python or
web2py that make this technique particularly appropriate ? Being new to
python etc. I thought it worthwhile asking.

The application that I have in mind has a number of one to many and a few
many to many relationships and in a number of cases I will want to use a
combined form with both the 'one' and one or some of the 'many' (perhaps on
a tabbed layout, or scrollable perhaps) almost certainly using Ajax to deal
with the different parts of the page.

It is interesting to look at the different frameworks and see the different
emphasis that each one has, and to see if that does have far-reaching
consequences, it's worthwhile spending a little time to try to make the
right choice.

thanks

graham

[Don O'Hara]

Hi Graham - Welcome to web2py ! I think you’ll find that this group
has many people who can share many types of design patterns.

Web2py has a lot of ajax built into core the framework. Since the original intent
was using web2py as a teaching tool, the emphasis may have been on simplicity (self submission).
Also, the introductory topic are several years old.

It would be interesting to hear your analyses of the other web/python frameworks
you have reviewed. “Which is best” is a frequent question on this group Of course,
“best” needs to be defined…


Don

> --
> Resources:
> - http://web2py.com
> - http://web2py.com/book (Documentation)
> - http://github.com/web2py/web2py (Source code)
> - https://code.google.com/p/web2py/issues/list (Report Issues)
> ---
> You received this message because you are subscribed to the Google Groups "web2py-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to web2py+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Anthony]

Much of the code used to create the form is also re-used when it comes time to process the submitted form, so submitting back to the same action helps avoid code duplication. You also don't have to worry about explicitly specifying a URL for submission. In any case, self submission isn't necessary. Do you have a reason for preferring an alternative pattern?

Anthony

On Thursday, June 19, 2014 9:30:15 AM UTC-4, Graham Ranson wrote:

I'm new to python and web2py...I have a small, but non-trivial, web ,

[Jim S]

I too did a double-take when I first saw this concept when learning web2py some time ago.  I came from a TurboGears environment and the self-submission was new to me.  I didn't like it at first, but now couldn't image being required to do anything differently.  Really simplifies/lessens the coding and has a cleaner thought process.  ...at least in my opinion.

-Jim

[Graham Ranson]

Don O'Hara <don.ohara@...> writes:

>
> Hi Graham - Welcome to web2py ! I think you'll find that this group
> has many people who can share many types of design patterns.
>

Thanks for the replies...

Just to mention the others: I had looked at Django and Turbogears briefly -
Django certainly gets the most mentions - at least sufficiently to feel
that they would do what I want and then I came to web2py. I've started more
seriously with web2py first simply because it was fresh in my mind, I'll
return to the others later; I've sort-of decided on a few small apps, say a
few days for each framework, although in order to keep the test apps
meaningful they won't be that trivial otherwise it could be a completely
unrepresentative exercise - so it may end up at more than a few days.

The sort of application that I am planning are not really web apps, but
intended for SMEs where there would run on a local network but, of course,
by using a web approach it is easy to run the same applications on the
Internet, a VPN, the cloud, use tablet/smartphone devices etc. and many of
those options are very likely to be used.

As for the self-submission: I cannot see much, if any, of the code that
would be involved in the preparation and creation of the 'new' form and
would be required for the validation and subsequent DB processing. Take as
an example an Employee and payroll function: there would need to be a
preliminary enquiry to establish whether creation of an Employee is
required or whether the employee already exists, this could be a separate
transaction or handled via Ajax when the relevant key fields (say name or
reference) were entered (fully or use a bit of auto-complete)

Then on confirmation that a new record was needed it would be necessary to
read a couple, at least, of parameter records to acquire a few default
values: some site preferences, some statutory; then the data for the
'create' page could be assembled, bearing in mind that a good number of
fields would not be user-editable, and some not normally user-viewable.
Then there are a good few one-to-manys in this example: there would
possibly be more than one address; probably more than one additional
contact (next of kin sort of thing); an employment history; set of skills
and more especially related to payroll. While it is not likely that
everything would be entered at the very first transaction there would be
quite an amount entered at the start.

A lot of 'validation' can be done on the client either by using selection
boxes (perhaps the options constrained by the site preferences) in
javascript but at the end there would need to be some validation by the
application and, of course, dealing with the creation of the two or three
(or more) subsidiary rows of the manys

I cannot see how that sort of interaction can be made to work with self-
submission and I cannot see how such a really not very complex data
creation procedure could be made any simpler.

graham

[Anthony]

If your going to use the web2py FORM or SQLFORM functionality, then the same code both defines and processes the form, so self submission makes sense. If you would rather build all of your form creation and processing code from scratch, then sure, do whatever you want.

Anthony

[Anthony]

Self submission is also handy when you need to re-display a form with error messages after failed validation, as you avoid the need to do a redirect and store the validation errors in the session.

Anthony

[Graham Ranson]

Anthony <abastardi@...> writes:

> If your going to use the web2py FORM or SQLFORM functionality, then the
same code both defines and processes the form, so self submission makes
sense. If you would rather build all of your form creation and processing
code from scratch, then sure, do whatever you want. Anthony

That's the issue really - whether my design lends itself to self-submisson
and if not whether not using those features of web2py that are built around
self-submission rather reduce the benefits of using web2py at all.
It's not that I cannot see a way to use self-submission but there are then
oddities - well they seem so to me - I notice that the book says:

"Pre-populating the form

It is always possible to pre-populate a form using the syntax:
form.vars.name = 'fieldvalue'

Statements like the one above must be inserted after the form declaration
and before the form is accepted, whether or not the field ("name" in the
example) is explicitly visualized in the form."

and to use the example from a few lines earlier:

def display_form():
record = db.person(request.args(0)) or redirect(URL('index'))
url = URL('download')
link = URL('list_records', args='db')
form = SQLFORM(db.person, record, deletable=True,
upload=url, linkto=link)

# pre-population would go here ?!

if form.process().accepted:
response.flash = 'form accepted'
elif form.errors:
response.flash = 'form has errors'
return dict(form=form)

in the example that I was thinking about that would involve a couple of DB
reads followed by the form.vars... assignments. Now if the same code is
then executed after submission how do these statements get handled ? I can
only suppose that re-executing the form=SQLFORM(...) has some magic in it,
but presumably not in the DB access and the form... assignments.
How does it deal with those ?

I've been otherwise occupied in the past few days and still haven't
actually done any work wit web2py yet...

graham

[Jim Steil]

I would handle setting defaults in the above example by setting the default value on the fields before the SQLFORM call like this:

db.person.name.default = 'fieldvalue'

-Jim

graham

--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---

You received this message because you are subscribed to a topic in the Google Groups "web2py-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/web2py/wbei89YDwL0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to web2py+un...@googlegroups.com.

[Anthony]

It would probably help if you show some code, or at least explain in more detail an example where self submission is not possible or overly difficult. Note, your code can always distinguish between a form creation request and a form submission request by checking whether request.post_vars is None or whether request.env.http_method == "POST".

As Jim suggested, if you are using SQLFORM, the easiest way to pre-populate is by setting field default values before form creation.

Anthony

[Graham Ranson]

Anthony <abastardi@...> writes:

>
>
> It would probably help if you show some code, or at least explain in more
detail an example where self submission is not possible or overly
difficult. Note, your code can always distinguish between a form creation
request and a form submission request by checking whether request.post_vars
is None or whether request.env.http_method == "POST". As Jim suggested, if
you are using SQLFORM, the easiest way to pre-populate is by setting field
default values before form creation.Anthony
>
>

Well, I cannot show any code - because I haven't written any real stuff yet
- and I cannot give an example of where self-submission could not work
because I haven't gotten to that point, yet (if at all). As I said I'm just
investigating but self-submission is one aspect of web2py that did stand
out to my superficial run through its features.
My experience in web-type applications is of the 'single purpose code'
type: one method assembles the data for the web page, from a database or
some default values etc., and then 'returns' it to the web client; then an
entirely separate method is the target for the subsequent HTML form
submission, it receives the data and creates the necessary data structure
(object or whatever) and populates it from the data on the POST, stores it
in the DB etc. This has a complete separation of functions.
And to some extent it is this lack of a clean separation that I find a
problem in the self-submission case, perhaps more philosophically than
practically, I'll agree.
But to return to the example I gave: I did quote from the book:

"It is always possible to pre-populate a form using the syntax:
form.vars.name = 'fieldvalue'

Statements like the one above must be inserted after the form declaration
and before the form is accepted, whether or not the field ("name" in the
example) is explicitly visualized in the form."

but are you suggesting that it is better to populate the db.tablename
object's defaults before the 'form=SQLFORM(...' statement ?
And I did suspect that there was some indicator used within the FORM object
- you mention request.post_vars being None, so if there were any complex
code to establish the pre-population values I should enclose that in a
condition like:

if request.post_vars == None:
#
# put pre-population data acquisition here
# including calls to other methods - if lengthy code
#
form = SQLFORM(...

Sorry to go on so...

Graham

[Jim Steil]

Yes, you set the defaults for the table before the form=SQLFORM(...) statement.  All you are doing is setting a default, you are not 'prepopulating' data.

Also, since web2py loads it's db.py on every request, the defaults you set in one request do not have an effect on subsequent requests.

Also note what Anthony said earlier, you don't have to use the self-submission paradigm.  You can force it to move to a different page on submission.

-Jim

Graham

--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---

You received this message because you are subscribed to a topic in the Google Groups "web2py-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/web2py/wbei89YDwL0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to web2py+un...@googlegroups.com.

[Anthony]

 My experience in web-type applications is of the 'single purpose code'

type: one method assembles the data for the web page, from a database or
some default values etc., and then 'returns' it to the web client; then an
entirely separate method is the target for the subsequent HTML form
submission, it receives the data and creates the necessary data structure
(object or whatever) and populates it from the data on the POST, stores it
in the DB etc. This has a complete separation of functions.
And to some extent it is this lack of a clean separation that I find a
problem in the self-submission case, perhaps more philosophically than
practically, I'll agree.

First, note that having the same action handle both form creation and form processing does not imply a lack of separation. You can still have different code paths and even entirely separate functions that handle different parts of the process, even if the same URL handles both cases.

Second, as already mentioned, there is some common code used for creation and processing, so self-submission helps to reduce code duplication as well as the use of redirects if you need to display validation errors or re-load a new blank form after a successful submission.

Third, nothing is forcing you to use the self-submission pattern if you really don't like it. For example, see http://web2py.com/books/default/chapter/29/07/forms-and-validators#Sharing-forms.

but are you suggesting that it is better to populate the db.tablename
object's defaults before the 'form=SQLFORM(...' statement ?

Specifically when using SQLFORM (which pre-populates fields based on the db.tablename field default values).
 

if request.post_vars == None:
        #
        # put pre-population data acquisition here
        # including calls to other methods - if lengthy code
        #
form = SQLFORM(...

Yes, something along those lines.

Anthony

[Graham Ranson]

Thanks for all the replies - I'll close this particular discussion now and
get on with writing some exploratory code, unfortunately, as always seems
the case, the past week or so has had rather too many, apparently urgent,
distractions...

But there is one thing I did want to mention re. http://web2py.com/books/
default/chapter/29/07/forms-and-validators#Sharing-forms. Indeed I did read
that section but it was the comment:
"What we discuss here is possible but not recommended, since it is always
good practice to have forms that self-submit."

that prompted me to start the thread, I was interested in why it was "not
recommended".

But, as the saying goes, I'll be back...(well very likely with more
questions)

And I will make at least a future post about the comparisons of the
frameworks.

graham

[Anthony]

But there is one thing I did want to mention re.  http://web2py.com/books/
default/chapter/29/07/forms-and-validators#Sharing-forms. Indeed I did read
that section but it was the comment:
"What we discuss here is possible but not recommended, since it is always
good practice to have forms that self-submit."

that prompted me to start the thread, I was interested in why it was "not
recommended".

In the Overview chapter in the section on Postbacks, there is this:

The mechanism for form submission that we used before is very common, but it is not good programming practice. All input should be validated and, in the above example, the burden of validation would fall on the second action. Thus the action that performs the validation is different from the action that generated the form. This tends to cause redundancy in the code.

There are other ways to avoid code redundancy (as in the shared form example), but the self-submission pattern is a handy one. As already mentioned, other benefits are that (a) you don't have to specify (and worry about possible future changes to) a submit URL, (b) upon failed validation, you don't have to store errors in the session and then do a redirect, and (c) after successful submission, you don't need a redirect if you simply want to reload a new empty form.

Anthony

[Cliff Kachinske]

Graham,

I have done form submission both ways. I much prefer self-submission. Much less code to write, so fewer opportunities for error.