> In the very first web2py code example in the manual, in the image blog
> example, we find this code in the controller:
>
> def index():
> images = db().select(db.image.ALL, orderby=db.image.title)
> return dict(images=images)
>
> Accessing from controller to the dal, in a simple query could not be a
> problem, but, what happen with a more complex query? With a three or four
> lines of code query, if we write it every time that we need the data in
> controllers, we are breaking DRY and MVC. But let´s supouse that we have a
> simple query like that, and we are using it in many controllers, if in some
> moment we need to change it, we need to go function by function in
> controllers to fix the problem. I know that I can put it with a function in
> the model, but the manual is saying that in web2py, the query goes in the
> controller.
>
Does the book actually specifically recommend that all queries go in
controllers? If so, can you point that out, as it should be changed.
Anyway, nothing about web2py requires you to put queries in controllers. If
it is a single query used in a single action, then sure, put it in the
controller. But if you re-use the same query in multiple places, of course
you should move it to a model or module -- this is the recommended
practice. web2py even allows you to define methods on database tables that
execute common queries. I don't see anything wrong with the example above
-- there would be no point to moving the query into a model file or module
for such a simple example.
> Another example is in the search function on the simple wiki:
>
> def search():
> """an ajax wiki search page"""
> return dict(form=FORM(INPUT(_id='keyword',_name='keyword',
> _onkeyup="ajax('callback', ['keyword'],
> 'target');")),
> target_div=DIV(_id='target'))
>
> Why create a form that not need any kind of postprocessing, even adding a
> onkeyup attribute, in the controller, when all this code, following MVC
> should go in the view?
>
I agree that could just as easily go in the view, but I don't see the harm
in having it here. Because most forms do involve processing/validation,
they are typically defined in controllers, so it makes sense to stick with
that standard even when no processing is happening. It's odd to say that
FORM(...).process() belongs in the controller but FORM(...) without the
.process() must go in the view.
Also, keep in mind that the overview chapter is just a relatively simple
introductory tutorial. It is not meant to communicate how one ought to
architect a large and sophisticated application. I'm not saying we couldn't
consider changing some of the code examples, but I don't see it as a major
indictment of MVC violation.
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 web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
