On Monday, February 9, 2015 at 10:49:10 AM UTC-5, Carlos Cesar Caballero
Díaz wrote:
>
>
> Can you point to an example of a query in the book that you think should
> instead have been shown in a model?
>
>
> All of them, or at least mention that queries should go in controllers,
> even a simple query, will represent a problem, if we need to change it and
> is used many times, new users, that read the image blog and simple wiki
> examples, should explicitly known that in web2py, the recommended way is
> putting the queries in models (or modules), all this in my opinion of
> course.
>
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).
> Of course, if you are working with designers who don't know and are not
> interested in learning Python, it makes sense to keep as much as possible
> in pure HTML. But that is not the only context within which web2py is used.
> If you don't want to use the HTML helpers, you don't have to, but that
> doesn't mean they should not appear in any book examples.
>
>
> We are moving away a bit from the main point, imagine that I made an
> application and my designer is learning how web2py views work and how
> helpers are used (which is exactly what is happening to me now), my
> designer does not have to look at the controllers, that is the goal of MVC
> , if I'm going to make changes in views, I do not have to know what is
> happening in the controllers. In the example that i mentioned, how I ask
> to a designer that modify a view that says:
>
> {{extend 'layout.html'}}
> {{=form}}
>
> Web designers normally know html and css, and if there is a way to easily
> separate views and controllers, then web2py is going to be easily adopted
> in teams with specialized members. But if I read in the main doc examples
> with view related code in controllers, then I not adopt the framework.
>
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).
Anthony
--
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.
