... this all _sounds_ great, but for one thing:
It places a dependency (an "import" or setup list) FAR AWAY from
where it should be declared!!!
This _will_ (sooner or later) become a problem.
Why not have something _less global_ (why _one_ config file???), and
more component / containment oriented?
Just to shift thinking, consider something like a decorator:
@depends_on( massimos_request_array )
@requires_login() # oh - I saw that post about default login; I
need to reply to it also
def my_controller_function:
...
The _only_ problem I see with this is that it implies that [1] the
controller is executed FIRST by default, AND for backward
compatibility, if there is _no_ dependency decorator, then the
implicit would be a "invisible decorator-like" behavior of execing
the entire models folder.
This _may_ need more code changes in gluon, but I suggest this would
be worth it.
Thoughts?
- Yarko
On Jun 10, 11:30 am, Thadeus Burgess <thade...@thadeusb.com> wrote:
> What if I needed two controllers to share the same model? Would I then
> place two definitions in request.models?
>
> Not 0.py that is not a valid python filename. Python modules/variables
> cannot start with numbers.
>
> how about just a simple "exec.py" that gets loaded before everything?
>
> --
> Thadeus
>
>
>
> On Thu, Jun 10, 2010 at 11:22 AM, mdipierro <mdipie...@cs.depaul.edu> wrote:
> > one we agree with the syntax, this is easy. The main issue is making
> > sure it works with bytecode compiled models.
>
> > On Jun 10, 11:20 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> >> Here is my proposal:
>
> >> define the following:
>
> >> request.models=(
> >> ('*','db.py'),
> >> ('*','model1.py'),
> >> ('*','model2.py'),
> >> ('default','model3.py'),
> >> ('default/a,default/b','model4.py'),
> >> )
>
> >> it specifies the order in which models should be executed. For each
> >> row, the first item specifies whether the model should be executed for
> >> all actions (*) for all actions in a controller (default) or only for
> >> specific actions (default/a, default/b). The second item in the model
> >> name.
>
> >> All models not listed would be executed in alphabetical order after
> >> those listed explicitly (backward compatibility).
>
> >> request.models would default to [].
>
> >> there would be a special model (execmodels.py? 0.py?) that would
> >> always be executed before every other model and it may override the
> >> value of request.models.
>
> >> all required code should go in a single place run_models_in() in gluon/
> >> compileapp.py
>
> >> Massimo
>
> >> On Jun 10, 10:56 am, Thadeus Burgess <thade...@thadeusb.com> wrote:
>
> >> > I like the idea of an execmodels.py file, it could create a list of
> >> > model names to execute.. Not yaml or cfg because that means web2py
> >> > would require yet another library
>
> >> > Massimo, tell me where this code *should* go and I will work on it
> >> > since this is a very important feature to me. Lets draft up a
> >> > specification and design first...
>
> >> > I will make a public google doc located here
>
> >> >https://docs.google.com/Doc?docid=0ActNNXQhkjU-ZGMyajJnbTdfOGZ3Z2IzOH...
>
> >> > everyone can edit this doc
>
> >> > What about requiring models from other apps? (i know apps arn't
> >> > supposed to depend on each other, but it might be a good option to add
> >> > so you *can* do it).
>
> >> > --
> >> > Thadeus
>
> >> > On Wed, Jun 9, 2010 at 11:42 PM, mdipierro <mdipie...@cs.depaul.edu>
> >> > wrote:
> >> > > They both make a lot of sense. The former would be much easier to
> >> > > implement and would result in faster code.
> >> > > What do other people think?
>
> >> > > On Jun 9, 11:32 pm, Salvor Hardin <salvor.pub...@gmail.com> wrote:
> >> > >> I'm new to python and web2py, so this might sound crazy but...here
> >> > >> goes.
>
> >> > >> Noob idea #1
> >> > >> Why not provide an optional "exec_models.cfg" file? If it doesn't
> >> > >> exist, execute *.py files in alphabetical order found in the models
> >> > >> folder.
>
> >> > >> This will maintain backward compatibility and give web2py more
> >> > >> flexibility.
>
> >> > >> If exec_models.cfg exists, then exec the files in the order specified
> >> > >> inside exec_models.cfg. If you want to get fancy, allow wildcards,
> >> > >> etc. Even better, you can also use exec_models.py or exec_models.yaml
> >> > >> instead of simple config.
>
> >> > >> Noob idea #2
> >> > >> Provide web2py's version of python's "import" function. Call it
> >> > >> "require(somefile.py)" and provide some web2py convention for
> >> > >> somefile.py to follow. That way, you can have require() detect and
> >> > >> decide what to do if somefile.py was already executed. Ruby has
> >> > >> "require" and rubygems added their own "require_gem()" function which
> >> > >> might provide useful ideas so you don't have to reinvent the wheel.
>
> >> > >> It is late, and these are ideas that surfaced in the mind of a python
> >> > >> and web2py noob. If you must laugh, do so with compassion. In the
> >> > >> meantime, I'll try to read at least one python book by next Monday.
> >> > >> Think Python is free online and looks like a quick one.
>
> >> > >> On Jun 9, 9:32 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> >> > >> > My approach is to use
>
> >> > >> > db_blablabla1.py
> >> > >> > db_blablabla2.py
> >> > >> > db_blablabla3.py
> >> > >> > ....
>
> >> > >> > where db_blablabla.py defiles all tables that link each other for a
> >> > >> > specific purpose. The different files are independent and therefore
> >> > >> > the order of execution is not important.
>
> >> > >> > On Jun 9, 9:20 pm, Thadeus Burgess <thade...@thadeusb.com> wrote:
>
> >> > >> > > There are some things you can do to alleviate the situation.
>
> >> > >> > > First, you can name you models so that they execute in the
> >> > >> > > correct order.
>
> >> > >> > > A_db.py
> >> > >> > > B_user.py
> >> > >> > > C_post.py
> >> > >> > > E_tag.py
>
> >> > >> > > That said, I usually try to keep all related models in the same
> >> > >> > > file.
> >> > >> > > In your case you might have
>
> >> > >> > > B_user.py
> >> > >> > > C_weblog.py
>
> >> > >> > > Since post and tag both belong to the same logical set of tables,
> >> > >> > > stick them together in one file. For objects, I also might subset
> >> > >> > > it
> >> > >> > > simpler such as
>
> >> > >> > > C_weblog.py
> >> > >> > > C_weblog_objects.py # contains virtualfield definitions.
>
> >> > >> > > --
> >> > >> > > Thadeus
>
> >> > >> > > On Wed, Jun 9, 2010 at 4:42 PM, mdipierro
> >> > >> > > <mdipie...@cs.depaul.edu> wrote:
> >> > >> > > > No. This the main issue with web2py design. This is the price
> >> > >> > > > we pay
> >> > >> > > > for not having imports of models.
>
> >> > >> > > > On Jun 9, 4:21 pm, Binh <btbinht...@gmail.com> wrote:
> >> > >> > > >> Hi,
>
> >> > >> > > >> I am trying to create an orm setup like in ruby on rails with
> >> > >> > > >> the DAL.
> >> > >> > > >> I have a user, post, and tag model.
> >> > >> > > >> A user has many posts.
> >> > >> > > >> A tag belongs to a user.
> >> > >> > > >> A post has and belongs to many tags.
> >> > >> > > >> A tag has and belongs to many posts.
>
> >> > >> > > >> I have 4 separate files in my models folder: db.py, user.py,
> >> > >> > > >> post.py,
> >> > >> > > >> and tag.py
> >> > >> > > >> db.py contains the db connection and mail configurations.
> >> > >> > > >> The respective model files define the table structure and have
> >> > >> > > >> a class
> >> > >> > > >> named after the model to implement virtual fields.
>
> >> > >> > > >> I noticed that defining the tables with relationships in the
> >> > >> > > >> separate
> >> > >> > > >> files does not work properly.
> >> > >> > > >> The model files would load which appears to be in alphabetical
> >> > >> > > >> order.
> >> > >> > > >> So, my db.py would load first and then post.py which fails.
> >> > >> > > >> post.py fails to recognize the table definition in user.py, so
> >> > >> > > >> it
> >> > >> > > >> cannot define the belongs to relationship.
>
> >> > >> > > >> Is their anyway to setup a model file to import all the other
> >> > >> > > >> models
> >> > >> > > >> without the hassle of file load order and possibly import
> >> > >> > > >> order which
> >> > >> > > >> rails does implicitly?
