This is what I desire from this

Web2py applications to be importable python modules
Along with [A] your models immediately become python modules that you
can import. This solves my need to share models between web2py apps.'

Web2py has a Top down approach, where other frameworks use a down-up
approach. Meaning, web2py executes the models THEN looks at the
request, determines the controller and executes it, then executes the
view. Everyone else does the down-top approach, where the request
comes in, it goes to the controller, the controller decides what
models to IMPORT and then executes itself and even decides what view
to return if any!

This is what the discussion has turned into, a design pattern, web2py
can never satisfy the down-top approach because of backwards
compatibility. Perhaps web3py.

--
Thadeus





On Thu, Jun 10, 2010 at 3:24 PM, Yarko Tymciurak
<resultsinsoftw...@gmail.com> wrote:
> On Jun 10, 1:17 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>> If we are going to work on this we may as well solve a different
>> problem.
>>
>> Executing models take time. If you have 500 tables each defined it its
>> own file, it takes lots of time. Yet not all actions need all tables
>> so we may want to implement a dependency not just among models but
>> among actions and models so that not-needed models are not executed.
>>
>> If the dependencies are expressed in the model files themselves they
>
> ... I assume you meant to say "...in controller files..."
>
>> still needs to be executed (or at least bytceode compiled) to be
>> resolved and that defies the purpose.
>> Moreover this would be similar to the python import mechanism (from a
>> user prospective) and thus an example of reinventing the wheel.
>
> ... if I am following you, then why do we not just import the needed
> models?  I mean, really, seriously - why the need to exec?
>
> It seems like that is a question on the table.
>
>>
>> Having a centralized place where these dependencies are expressed has
>> advantages:
>> - sets us a apart from everybody and we do not need to reinvent the
>> wheel
>
> Global variables in FORTRAN had proponents too - but the need to
> manage complexity drove a different structure in programming.
> (That is to say, I am not seeing, am challenging that there are _any_
> REAL advantages to centralized dependency management;)
>
> ==>  "set us apart" is not any kind of advantage, if it does not
> provide tangible benefit.  (that is, benefit may drive what sets
> web2py apart, but making "set apart" a motive is not beneficial in and
> of itself - this should be very clear).
>
> If there is a current wheel that is useful, use it.
>
> $ python
>>>> import this
>
> one way is better;   if there is something that currently solves the
> problem, use it (don't 'reinvent the wheel';  _and_ don't look for
> problems as an excuse to invent a wheel)
>
>
>> - it will make the structure of the application easier to read in a
>> single place
>
> ... I don't agree, don't see this as beneficial; harder to maintain;
> related information scattered;
>
>> - it will make the app faster
>
> ... this is not a benefit - it is a goal;   you are implying that
> centralized models are the only way to make an app faster;   I'm not
> buying; I don't think that's true at all.
>
>> - it will be easier to implement without breaking backward
>> compatibility (and there it will get done)
>
> .... simplicity of implementation is a benefit to _you_;   but (while
> that may be important to you), simplicity to implement applications
> (since it happens more frequently) is first in line;  _then_
> simplicity of implementation, practicality;
>
> .... I don't see this as a benefit of central place;
>
>> - it will open the possibility for dependencies to be auto-discovered
>> and therefore the config-file auto-generated
>
> ... actually, you could generate (if that were the most practical way)
> a central dependency list from local declarations (which is how
> Windows Registry works);
>
> I don't see this is a benefit of "central place", rather a practical
> consideration.
>
> ... this is beginning to feel like an old tet-a-tet.
>
>
>>
>>
> ...
>

Reply via email to