On Wed, Oct 21, 2009 at 3:52 PM, mdipierro <mdipie...@cs.depaul.edu> wrote:
> >> On Oct 21, 2:46 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: >> > Yarko, >> > >> > I agree, hacking is bad, hacking leads to unmaintainable code except by >> > those who wrote it (if then). Hacking around a current system leads to >> low >> > quality software in the end, hacking leads to either projects being >> > abandoned by their users, or required rewrites which waste time. >> > >> > I dislike it when a system is not changed to be what would perfectly >> suite, >> > but hacked together to fit into the mold of the existing system (govt >> > anybody?) >> > >> > And since plugins are not in web2py yet, we have no backwards >> compatibility >> > to break, lets do this right. >> > >> > I really agree that the design of plugins NEEDS to be modular, logically >> AND >> > physically. >> > >> > Mr. Freezes suggestion is the best layout I have seen so far, and what >> is >> > the problem with scanning the plugins folder? >> > >> > This does not make web2py more clunky, it makes web2py more structured. >> > >> > Only look for a plugin when LOAD() is reached. If it is found, great >> load >> > it. If not, raise an exception. >> >> I would agree if this were possible. You need to look for a plugin >> when the plugin submits a form to itself, that is when a HTTP request >> arrives, as for any HTTP request. >> >> What you suggest (functionally) is like defining models at the top of >> controllers. In this way the plugin model would only be visible to the >> plugin controller code. This is very limiting. appadmin would not be >> able to see the tables defined by plugins. The main app would not be >> able to set or override global variables defined by plugins, nor >> access their tables. >> > > This is an artifact of the assumptions of this implementation - if you look > at layered development models, > there is a utilities block in most every one that I've seen (which has been > useful) that is available accross the layers. > That is ONE thing missing in this model (web2py). > > BUT the plugin you define has it's own model/view/controller layers, so > that begs the question: utility structure? Co-routine (co-application) > structure? > What is the appropriate model for this, and what do we need to get to it. > > Again, all these complaints do not point out anything to me but that the > definitions / specifications (not the semantics) are not yet complete - more > discovery, thinking, discussion, and (when appropriate - as is, it seems to > come prematurely) prototyping in the context of overall objectives. > > >> >> > There is no reason to load the plugins every time a page loads unless >> their >> > used on that page, makes them light. >> >> I think we have to be pragmatic about the model/view/controller >> design. If this is what you try to achieve then a plugin could be just >> a controller that define_tables(s) in the controller itself. And again >> you can do that now if that is all you need. >> > > You are talking about separation of concerns (much more than directories) > but you have not addressed what the separation of concerns is between a > plugin and an application... If you have one plugin, shared by apps > (something you have shown how to do), how does db (connection) issues / > sharing work? > > This is about defining what the needed interfaces are, and what the > appropriate separation of concerns is.... and that will come naturally from > describing what a component consistes of, and what the responsibilities > (concerns) of the constituent part are, and how they relate (interface) with > the app, and if it can interface with multiple apps... > > > >> >> > Admin would be the only place web2py would have to "auto discover" what >> is >> > in the "plugins" directory, and even it, its just a listing the folder >> names >> > in the plugins subfolder. >> >> That is what it does now. Discovers all files/folder starting with >> plugin_[name] and groups them by [name] into separate pages. >> > > Implementation details.... too soon; do not constrain yourself with these > now... > > >> >> One again. This is not the end of the story. I welcome this >> discussion. I have been proven wrong before. :-( >> > > Everyone is ignorant in something; everyone is smart in something; it's > not about being wrong or right - its about being able to see a bigger > picture, a piece not easy to see alone - with the open involvement of > community! > > :-) > - Yarko > > >> >> Massimo >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
