Carlos, You bring good points to consider and Anthony brings some perspective too. I don't think there is a single answer here, but I think that web2py allows someone to do what is right to do depending of the context... The fact that the book may be misleading if you applied simply it examples can be fixed. So your comments have been heard and will serve to improve documentation.
Richard On Tue, Feb 10, 2015 at 6:00 AM, Carlos Cesar Caballero Díaz < [email protected]> wrote: > > 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. > > -- > 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. > -- 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.
