On Jun 10, 3:44 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > 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. I think you're mixing metaphors here - top-down typically refers to solution "top" being more abstraction, "bottom" being more implementation. In any case, controllers are more abstract in the sense that they delegate to more details, so if anything the description might be that web2py does bottom-up (get all the details in place, then call the entry point - ooops! we didn't need all those details, oh-well!). > 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. I do not think those two things are coupled - I think you can "import the world" (e.g. web2py model handling currently) as a default way of achieving backward compatibility... So the question still returns to the problem space - and you've added one problem: wanting to share models among we2py apps (e.g. make something like modules of them). Kind regards, - Yarko > > -- > 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. > > > ...
