Optimal MVC forms summary?

[carlo]

I wanted to make the point on one of my favourite subjects, forms
designed in the best MVC pattern possible, so I browsed the forum
searching for the latest achievements to this respect. I found
different solutions but they looked a bit more like extemporaneous
tricks than a reference "how to". I found to different degrees: Bill's
Patch, DenesL custom forms, rfx_labs custom forms (where you can find
the underdocumented "form.element" syntax) and forms "the Tim Farrel"
way.

I can not understand why in the documents/tutorial/examples forms are
always designed in a usual "everything in the controller" pattern:
saying "always" maybe I am exaggerating a little, but this is the
trend. I find this a bit uneducating because it brings to coding
controllers just the worst php manner. I would prefer there was a
"suggested" web2py way used throughout every example.

My "good " forms, at least:
- data queries in controller or model
- define a "form" object in controller is acceptable
- helpers and/or html in views
- validation facilities must be preserved
- forms auto submitting must be preserved

May I ask someone to summerize, as 1.56.3 version is out, the best/
suggested way to design forms following an MVC pattern as clean as
possibile? Thank you

carlo

[Timothy Farrell]

What you're asking about is very close to "The Tim Farrell way" Maybe
you should take a closer look at it. The only differences I see are:

- I didn't use helpers with my template code (but you are free to)
- Validation facilities are limited to one form per page with a few
applications

=)

--
Timothy Farrell <tfar...@swgen.com>
Computer Guy
Statewide General Insurance Agency (www.swgen.com)

[carlo]

Thank you Tim, I already used your method in some tests and it's
fine.
I was just asking if among that mass of "custom forms" posts there was
something new and "standard" in the web2py sense.

I am really wondering if we want to promote this kind of coding as the
"web2py way":

form=FORM(TABLE(TR("Author:",INPUT
(_type="text",_name="author",requires=IS_NOT_EMPTY())),
TR("Comment:",TEXTAREA
(_type="text",_name="body",_rows="10",_cols="40",requires=IS_NOT_EMPTY
())),
TR(INPUT(_type="hidden",_name="book_id",_value=request.vars.bid)),
TR("",INPUT(_type="submit",_value="Submit"))))

and this is just the smallest example you can find in the web2py free
appliances.
And I can not even post my 20 line forms I have in a controller of one
of my first web2py app.

From my past experience I am a little scared about building my next
form intensive app based on such examples.

carlo

> Timothy Farrell <tfarr...@swgen.com>

[DenesL]

On Feb 17, 6:03 am, carlo <syseng...@gmail.com> wrote:
> I wanted to make the point on one of my favourite subjects, forms
> designed in the best MVC pattern possible, so I browsed the forum
> searching for the latest achievements to this respect. I found
> different solutions but they looked a bit more like extemporaneous
> tricks than a reference "how to". I found to different degrees: Bill's
> Patch, DenesL custom forms, rfx_labs custom forms (where you can find
> the underdocumented "form.element" syntax) and forms "the Tim Farrel"
> way.

I guess I missed some of those.
Did you make a note of which posts are they on?.
I would like to read them without having to search, which brings us to
the next point...

>
> I can not understand why in the documents/tutorial/examples forms are
> always designed in a usual "everything in the controller" pattern:
> saying "always" maybe I am exaggerating a little, but this is the
> trend. I find this a bit uneducating because it brings to coding
> controllers just the worst php manner. I would prefer there was a
> "suggested" web2py way used throughout every example.

Many new features (good) documented in posts and/or alterego and/or
you-name-it (bad).
We need to centralize & update the docs too.

>
> My "good " forms, at least:

I think the custom objects in SQLFORM pass the test:

> - data queries in controller or model

and using keepopts saves you another DB query

> - define a "form" object in controller is acceptable

this is a must

> - helpers and/or html in views

check

> - validation facilities must be preserved

just remember to name your elements

> - forms auto submitting must be preserved

use <form action="" ...>

> May I ask someone to summerize, as 1.56.3 version is out, the best/
> suggested way to design forms following an MVC pattern as clean as
> possibile? Thank you

After reading the different "ways" we might get together and work
something out.
Tim? Bill? Carlo...

[carlo]

Tim Farrel's way:

http://groups.google.it/group/web2py/msg/6730f1fe4502684c

rfx_labs:

http://groups.google.it/group/web2py/msg/303b8d25eb74ed91

Bill's patch debate:

http://groups.google.it/group/web2py/msg/66ee7169675c1195

> I think the custom objects in SQLFORM pass the test:

Frankly, I do not think this is a good solution though I admit I did
not use SQLFORM extensively in the past. To my knowledge, SQLFORM is
useless with forms involving data from many to many relations, that is
the 90% of real everyday forms.

Hope we can get to collect some general directions..thank you for your
help.

carlo

[AchipA]

web2py gives quite some latitude with regard to doing things... I
understand there are major no-nos, but is there a best way ? We had
that discussion of putting common stuff in models, I'm not that sure
about the helpers only in views either (I use them in controllers,
when there is a reason - FORMs are a good example). MVC is (very) good
practice, but I don't think it should be so blindly adhered to it that
it becomes the only criteria of code quality (especially as the MVC
pattern doesn't completely fit web development).

[carlo]

On 17 Feb, 23:39, AchipA <attila.cs...@gmail.com> wrote:
> web2py gives quite some latitude with regard to doing things... I
> understand there are major no-nos, but is there a best way ? We had

Sorry but I would be more narrow minded about this: from my point
there *should* be never a good reason to put html in controllers: it
makes code difficult to debug, to read and to share with designers.
Isn't this one of the reasons for php and java servlets failure in the
enterprise?

carlo

[AchipA]

One of the returning moments on this list is that when I say helpers
in controllers, people hear 'html in code'. The two have (almost)
nothing in common, even though it's possible to overuse/abuse helpers
(just as you can put html in strings in controllers - obviously bad).
Then again, maybe it's just me having an awkward POV on helpers :)

My main question is - why do people consider transferring only stock
variable/list/dictionary python objects to the views 'cleaner' than
transferring any other python object to it (helper objects, or even
your own) ? Helpers create *objects* which are just data wrappers.
They are *NOT* strings and have nothing in common with HTML until the
point they get rendered.

[carlo]

everything is debatable: only side thing I can argue is that helpers
are objects related to markup and I do not like them mingled with
logic. But that's philosophy I agree.

The main real point is that if you want to share your work with html
designers, you can not use helpers at all. Your designer gives you
markup and style: the more you have this separated from your logic the
better integraton ease.

carlo

[AchipA]

A helper object can be used almost identically to a list. Helpers
being able to 'render' themselves and including additional data (to
ensure compliance, etc) is just a bonus for rapid prototyping. If you
*depend* on rendering (and you need to hand that over to a design
person), then you are likely abusing them (just like including html in
your controller response is MVC abuse), but otherwise, there is
minimal difference.

I would seriously like to hear Massimo why he introduced HTML helpers.
I personally find them very useful, but I'm not certain we're all
talking about the same thing here with regard to MVC.

example controller:

return dict(listdata = (('col1', 'col2', 'col3'),('1','2','3'),
('4','5','6')), helperdata = TABLE(TR('col1', 'col2', 'col3'), TR
('1','2','3'), TR('4','5','6')))

example view (I know this can be written in a more compact manner, but
let's keep things simple for designers):

Oldschool:
<TABLE>
{{for row in listdata:}}
<TR>
{{for cell in row:}}
<TD>{{=cell}}</TD>
{{pass}}
</TR>
{{pass}}
</TABLE>



Rapid prototype (designers can also use CODE, BEAUTIFY, .xml(), etc):
{{=helperdata}}

Oldschool, but based on helper data:
<TABLE>
{{for row in helperdata.components:}}
<TR>
{{for cell in row:}}
{{for data in cell:}}
<TD>{{=data}}</TD>
{{pass}}
{{pass}}
</TR>
{{pass}}
</TABLE>

See ? It's the almost the same thing, helpers are just custom objects,
you can do with them as you please.

[carlo]

I have nothing against helpers as I use them a lot when involved with
a project to accomplish alone.

Working in team they are almost useless: the html code is usually the
source for your logic not a "product" to pass designers. You get html
static pages with style and putting in some logic is your business.
Seldom, at least in my everyday work you get the reverse.

>>designers can also use CODE, BEAUTIFY, .xml(), etc):

maybe in my dreams :-) They give you html and want back html to check.

Another issue is readability, the common "web2py mode" that I call
"everything in controllers" leads easily to monsters like this:

f2=FORM(FIELDSET(TAG.legend('COSTI JOB1',_id='daticosti'),\
TABLE(TR(TH('Lavoro/Materiale'),TH('UM'),TH('QT1/QT2/QT3'),TH
('Costo Un.'),TH('Totale')),\
TR(TD('Carta'),TD('Kg'),TD(SPAN(_id='carta_qt')),TD(SPAN
(_id='carta_cun')),\
TD(SPAN(_id='carta_tot'))),\
TR(TD('Lastre'),TD('Nr'),TD(SPAN(_id='lastre_qt')),TD(SPAN
(_id='lastre_cun')),\
TD(SPAN(_id='lastre_tot'))),\
TR(TD('Tiratura'),TD('min'),TD(SPAN(_id='tiratura_qt')),TD(SPAN
(_id='tiratura_cun')),\
TD(SPAN(_id='tiratura_tot'))),\
TR(TD('Avviamenti'),TD('min'),TD(SPAN(_id='avviam_qt')),TD(SPAN
(_id='avviam_cun')),\
TD(SPAN(_id='avviam_tot'))),\
TR(TD('Inchiostri'),TD('perc'),TD(SPAN(_id='ink_qt')),TD(SPAN
(_id='ink_cun')),\
TD(SPAN(_id='ink_tot'))),\
*[TR(rows_lavor[i]['descrizione'],db2(rows_lavor[i]
['idutilizzo_um']==db2.um.id).select(db2.um.nome)[0].nome,\
TD(INPUT(_id='lav_qt'+str(rows_lavor[i]
['id']),_class='lavj1',_value='0',_name=str(rows_lavor[i]['id'])),\
INPUT(_id='lav_qt2'+str(rows_lavor[i]
['id']),_class='lavj1',_value='0',_name=str(rows_lavor[i]['id'])),\
INPUT(_id='lav_qt3'+str(rows_lavor[i]
['id']),_class='lavj1',_value='0',_name=str(rows_lavor[i]['id']))),\
' eur '+('%.2f')%(rows_lavor[i]['costo']),\

....more

But I would not like to diverge from the central point: is there a
"style" we can agree to be regarded as a good web2py manner to code
forms? A part from our helpers debate, there are people who simply do
not want to use them (Tim Farrell is one of them I think I remember):
can we simply give a clear direction to people like that? Farrell had
to make his method up.

Also not any form can be auto submitted (and forms.accepts is not
available): what about forms submitted with ajax get/post ( a style
increasingly popular) ? In this case it is useless even to keep the
form object in controller.

carlo

[AchipA]

On Feb 18, 7:43 pm, carlo <syseng...@gmail.com> wrote:
> Working in team they are almost useless: the html code is usually the
> source for your logic not a "product" to pass designers. You get html
> static pages with style and putting in some logic is your business.

I guess I'm just terrible at expressing myself. There is no
uncrossable difference between helpers and plain lists/dicts, and thus
there doesn't need to be any appreciable difference in templates using
one over the other, either. On the other hand, while the designers are
sleeping, the coder CAN use the helper's native output to speed up
prototyping and ensure standards compliance.

Sometimes I even use two separate views for the same controller
function - one from the 'designer' and one for development. The
helpers in this sense make it actually easier to work in teams. As the
controller output is the same, I can mess with my functionality/
debugging oriented views, while not breaking the 'simple', element
oriented view supplied by the designer.

To reiterate - the way I see it helpers are objects just like lists or
dicts and can thus be used in the same way with regard to controllers
or views. If you do not get carried away, you only gain additional
functionality compared to the case you skipped using helpers
altogether and thus it cannot 'worsen' MVC compatibility or teamwork
than what the basic MVC model already requires/allows for. To all who
I have not convinced and/or have wasted their time to read my lengthy
posts about this arguably philosophical point - sorry, I'm over and
out :)

[carlo]

discussion has shifted on helpers that I love but I do not suggest
them working in team with designers. Helpers can fail on readability:
try 4-5 annidated helpers each with 3-4 properties.
My topic was rather different.

- a clean separation between markup and logic is advisable or you
fall in java servlets or php

- the "everything in controllers" style easily leads to messy code
(see example above)

- one of the best solution at the moment is Tim Farrell's (see link
above)

carlo

[AchipA]

On Feb 18, 10:53 pm, carlo <syseng...@gmail.com> wrote:
> discussion has shifted on helpers that I love but I do not suggest
> them working in team with designers. Helpers can fail on readability:
> try 4-5 annidated helpers each with 3-4 properties.

It's the same as trying a 4-5 dimensional dict/list with 3-4 elements
each. You don't want to be doing that either.

> -  a clean separation between markup and logic is advisable or you
> fall in java servlets or php

Been there, done that for quite a while, I agree with what you say
above, but do not consider helpers markup.

> - the "everything in controllers" style easily leads to messy code
> (see example above)

Yes, helpers, just as almost any other pattern, can be abused. You
don't use helpers to generate static html or complete pages/gigantic
forms from it - I agree that the example you give is an example how
NOT to use helpers (unless you're MDP ;) - but not as an example
helpers should not be used in controllers. You should use it to handle/
prepare dynamic data, in small, understandable chunks, if it's static -
> it's a view. If it's complex -> it needs to be broken up and
assembled in the view. Don't be afraid to manipulate helper objects
from a view !

You could just the same way return a string containing markup or raw
javascript which would be just as bad, but that does not mean
returning variables breaks MVC, but that you misuse the mechanism.

> - one of the best solution at the moment is Tim Farrell's (see link
> above)

Glad you like it, but can we vote ? :)

There, promised not to respond, but still had to :) Must ...
resist ... :)

[carlo]

:-)

> It's the same as trying a 4-5 dimensional dict/list with 3-4 elements
> each. You don't want to be doing that either.

with helpers you get a clear advantage: you can easily get rid of them
if you want, sometimes more difficult with lists.

>
> > -  a clean separation between markup and logic is advisable or you
> > fall in java servlets or php
>
> Been there, done that for quite a while, I agree with what you say
> above, but do not consider helpers markup.

what about an unnecessary layer of code?

>
> > - the "everything in controllers" style easily leads to messy code
> > (see example above)
>
> Yes, helpers, just as almost any other pattern, can be abused. You
> don't use helpers to generate static html or complete pages/gigantic
> forms from it - I agree that the example you give is an example how
> NOT to use helpers (unless you're MDP ;) - but not as an example
> helpers should not be used in controllers. You should use it to handle/
> prepare dynamic data, in small, understandable chunks, if it's static -> it's a view. If it's complex -> it needs to be broken up and
>
> assembled in the view. Don't be afraid to manipulate helper objects
> from a view !

what I wanted to prove is that mainstream web2py examples and even the
book seem to promote a coding style which easily can lead to the above
example. Forms with 4 fields and 2 tables are good, but if you have 10
fields and 10 table datasource?

> You could just the same way return a string containing markup or raw
> javascript which would be just as bad, but that does not mean
> returning variables breaks MVC, but that you misuse the mechanism.

About MVC we do not agree.
I share this line:

http://groups.google.it/group/web2py/browse_thread/thread/4cd0a75de54f32aa/6312be3940d30fa4?lnk=gst&q=mvc#6312be3940d30fa4

http://groups.google.it/group/web2py/msg/c096da7eb69c4d64

and other Billf tries to free from forms in controllers.

> > - one of the best solution at the moment is Tim Farrell's (see link
> > above)
>
> Glad you like it, but can we vote ? :)

yes you can, it is explicit in the topic question mark :)

> There, promised not to respond, but still had to :) Must ...
> resist ... :)

I will give you the last word, I promise :)

carlo