On Jun 10, 12:37 pm, Doug Warren <doug.war...@gmail.com> wrote:
> That's kind of what i was getting at with my suggestion listed above
> in some pseudocode.
Right - except for this:
[[for those that "read" all-caps as "yelling" (who the heck thought
that? CLEARLY not anyone that was alive, or could have worked on a
TTY machine!!!) --- since I there is NO other way to add EMPHASIS ---
that is what I am doing with ALL-CAPS: translate it as BOLD when you
read; and _this_ is my way of adding italics;]]
Right now, gluon/main BLINDLY sets up an execution environment /
setup for ALL requests by ASSUMING that each request will need ALL
models;
What is _really_ the first thing called is controller/
requested_controller()
I am suggesting this is the tip of the bigger problem: that gluon/
main() assumptions are not functional, no longer live.
That is to say: exec'ing models is the _wrong_ model to begin with.
IF you can (just for the sake of argument) swallow that, then models
should NOT be the first thing looked at AT ALL:
INSTEAD: controller / function should be called, and (with a
decorator) it's environment setup _as that controller requests_
(so - forget about the models files being looked at _before_ the
controller: that is too much like "big brother" deciding for
controller the execution environment).
As I write this (I _am_ thinking out loud), I am aware that the place
for Massimo's request.models[] list is, in fact NOT in a separate
file (exec.py), and NOT in the models folder - rather, at the head of
the controller file.
For example:
default.py:
request.models[ # you could define all models here, if desired , and
this would apply to all functions for this file ]
This way, controllers could have utililty files which were not reading
in anything.
I'll let those worried about "backward compatibility" figure out how
to read ALL the models, if there is no exec.models....
So - this turns on it's head (appropriately, I think) a core way that
gluon behaves in setting up for a request (and I think this is a
needed shakeup).
More discussion, thoughts?
(maybe this should move to the web2py developer's thread?)
- Yarko
>
> Let the model try to grab it's required modules if it can't find one
> it'll just raise an exception and it'll be tried again later.
> Eventually all dependencies that are solvable will work themselves
> out...
>
> (Only I wrote while 1: in the pseudocode, and I meant while
> delay_process, but that's why it's psuedocode)
>
> On Thu, Jun 10, 2010 at 10:25 AM, Yarko Tymciurak
>
>
>
> <resultsinsoftw...@gmail.com> wrote:
> > ... 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?
