That's kind of what i was getting at with my suggestion listed above
in some pseudocode.
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?
