I disagree that all queries belong in models. A complex query that
needs to be re-used in multiple places should go somewhere centralized
(not necessarily a model file, but perhaps a module). However, not all
queries need to be re-used. Furthermore, some queries are so simple,
there is no point in abstracting them into a re-usable function/class
(e.g., selecting all records and fields from a single table).
Apps grow in time and we never known if in a future we will need to
reuse a query, what happen if a client, in some moment decides that he
don´t want to work with the data of more than one year ago, but it
should remain in the DB? (Because so much data bothered and there is
other software for data analisys) Then will be necessary to change so
simples queries one by one.
The first two examples in the tutorial show forms in pure HTML.
Furthermore, in the forms chapter, there is a section on using HTML
for forms
<http://web2py.com/books/default/chapter/29/07/forms-and-validators#SQLFORM-in-HTML>
as well as a section on custom forms
<http://web2py.com/books/default/chapter/29/07/forms-and-validators#Custom-forms>,
which shows how you can use custom HTML but still take advantage of
some attributes provided by the FORM helper. I think it would be fine
to add some verbiage to the book making it more explicit that these
techniques might be particularly beneficial when working with
designers (e.g., "If you are working with designers who only know
HTML, you might want to lay out your forms via the methods described
in the Custom Forms section."). That doesn't mean it's wrong to have
some examples showing the use of helpers.
Also, encountering {{=form}} in a template doesn't have to stop a
designer from contributing. If the form is laid out as desired via
{{=form}}, then the only thing the designer need touch is the CSS. On
the other hand, if the form is not laid out as desired via {{=form}},
then you need custom HTML anyway, and at that point, the designer can
just go ahead and implement the HTML in the template (which you might
later abstract into a custom formstyle function).
Yes, but why not in the first two examples? (the image blog or the
simple wiki)
I do not really like to continue this discussion, from the beginning I
just wanted to comment on the reasons why some experienced web
developers I know have rejected web2py after reading only part of the
manual.
Cheers.
--
Este mensaje le ha llegado mediante el servicio de correo electronico que
ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema
Nacional de Salud. La persona que envia este correo asume el compromiso de usar
el servicio a tales fines y cumplir con las regulaciones establecidas
Infomed: http://www.sld.cu/
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
