On Feb 19, 2:14 pm, bruno desthuilliers
<bruno.desthuilli...@gmail.com> wrote:
> On 19 fév, 15:38, Wiiboy <jordon...@gmail.com> wrote:
>
> > And the explicit vs. implicit imports: Personally, I love the fact
> > that the request object is available all over the place, including
> > models, and that I don't have to do any importing.
>
> As far as I'm concerned, it's a definitive No-No. The request is only
> meaningfull in the context of a request handler (whether you call it
> 'view' or 'controller'). The model part must *not* depend on it. And
> it's not a dogmatic POV - it's based on working experience with
> frameworks that happily mixed orthogonal concerns and ended being a
> major PITA.
Our definition of models is a little different than Django's and this
may lead to some confusion. We have two app sub-folders: models/ and
modules/. Files in models/ are executed and they contain code that
prepares the environment seen by controllers and templates. Files in
modules/ can be imported normally. It is custom for web2py users to
put table definitions in models/ but you could very well put them in
modules/ and import them as you do in Django. The reason we normally
put we table definitions in models/ is because out tables contain meta
information relative to presentation of the information, validation,
access control and internationalization, and for these to work they
require a request object. Think for example of a table with a field
that is never displayed but always contain the ip address of the
client who updated the record. We would just do
db.define_table(....,Field('client_ip',update=request.client,writable=False))
If you were to put such code in a module/ as opposed to a model/ you
would have the problem of passing a request object to it and you'd
probably end up with more logic in controllers. Yet I do not know
Django that well so you probably have an equivalent way of achieving
the same.
Another reason to do what we do is that we support multiple database
connections. If we put table definition in a module we would have
somehow to specify which database connection to use (and this also may
depend on other request parameters).
Anyway putting table definitions in models has disadvantages too. The
major one is that if you want to run them in your own python code (not
the framework) you still need to use the framework API.
I am not saying web2py approach is better than Django's here. I am
just saying we tried Django's before implementing it this was. This
design was not an accident but a consequence of carefully considering
pros and cons. We took a pragmatic approach not a purist one.
Massimo
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
