On Sat, Oct 24, 2009 at 10:23 AM, mdipierro <mdipie...@cs.depaul.edu> wrote:
> > To understand better your point view. > > If plugins were to be stored in a subfolder "plugins/" but worked > exactly how I suggested, i.e. executed in the same order as if all > models where in the same models/ folder, would this be ok? > > Massimo > This is one potential solution. To understand my point, a plugin should be a "plugin" in the sense that it is self-contained, and fits an interface, that is - plugs in. To be self contained (not necessarily hard enforcemen) - the code should not be mixed in and openly visible (not separated) with application code. There is, I am sure, more than one way to do that. For example, subfolder "plugins" within the applications area would be one; I am not sure, but possibly a subfolder "plugins" within the application itself might also work. As for "...exectuted in the same order as if...." --- this presumes some design decisions that have not been specified nor well discussed (considered). For example: Should a plugin be instantiated with gluon? (and thus available to any application that creates a plugin object of the specified plugin...) Should a plugin be instantiated on plugin declaration by the application (as might happen with an applications/plugins folder)? Should a plugin be instantiate on request, as models and controllers currently are? (I like this the least, as it makes for potential plugin exectution when they are not used). In any case, these are some of the implications and results that have not been explored or discussed, and I feel strongly should be. As for the general concept of increasing the sense of encapsulation, I think you are beginning to get sense of my intent (perhaps not yet the full strength of it). Regards, Yarko > > > On Oct 24, 9:40 am, Yarko Tymciurak <resultsinsoftw...@gmail.com> > wrote: > > On Fri, Oct 23, 2009 at 11:09 PM, mdipierro <mdipie...@cs.depaul.edu> > wrote: > > > > > It seems to me this would move us completely in the wrong direction. > > > > First, since you are not writing in context, I will guess you are talking > > about the concept that suiato presented of all [model, view, controller] > in > > on class. > > > > This concept as is, is simply not workable, as you can see from simple > > "units" analysis - models and controllers are Python code; views are / > > consist of html/template code (different base). > > > > I agree with massimo that it makes no sense to organize this particular > way. > > > > However, a plugin_controllers class, and plugin_models class might have > more > > merit for discussion - but has the problem of consistency: what would > the > > "matching" idiom be for plugin_views (well, it could be just an anolog in > > directory structure). > > > > This leaves on the table the discussion: is directory structure or class > > structure a better way to incapsulate (Massimo: you will note, please, > that > > I am still very firmly of the stance that mixing in code with files > called > > plugin_[plugin_name].py is not an acceptable idea - not acceptable for > me, > > because of all the issues I see down the road with it; I have seen NO > data > > which even slightly moves me from that position, so I will not consider > that > > structure as a viable option). > > > > It would create a lot of structure one would need to remember. It > > > > > creates a new programming paradigm where for plugin models/view/ > > > controllers are no longer separated in files but stored together in > > > the same file. > > > > I think the statement of models/view/controller as separated, similar to > the > > rest of the app is clear. There is no reason to think that this kind of > > structure would be of any benefit / use. > > > > > I like the idea of a web2py online conference. I could actually > > > organize one in Chicago at no cost (except for flight, lodging and > > > food) but would be people be available to fly here? Online may be a > > > better option. > > > > Online: there are several options, including IRC. > > > > A good topic would be review of design of web2py, and workshops to > identify > > problem areas (coupling) where attention would reap the biggest benefits. > > Plugins (and specifying them) would be a good topic, but for this to > > produce useful results, the participants would have to be senior > engineers / > > computer scientists (novices will have many ideas, and can help with > > specification, but structure - architecture and design discussions - will > > require more seasoned participants for satisfactory results). > > > > - Yarko > > > > > > > > > Massimo > > > > > On Oct 22, 11:10 pm, suiato <homm...@gmail.com> wrote: > > > > hi all, > > > > > > although i'm a mere user who may not have full understanding of > web2py > > > > mechanisms, i'm interested in how the web2py plugin system is > > > > developed thru these discussions. because it will affect the > evolution > > > > path of this software, and probably decide if or how i am going to > use > > > > this system in the future. complex/commercial/enterprise applications > > > > like CMS or e-commerce would benefit from smart and easy plugin (or > > > > add-on or extension) systems. > > > > > > 2009/10/23 Yarko Tymciurak <resultsinsoftw...@gmail.com> > > > > > > > Or what about one plugin file, where each plugin is a class - > perhaps > > > one for controller, one for model - no views allowed (only app or gluon > > > facilities; could worry about separate view plugins as that is > different > > > enough).... > > > > > > i am interested in the idea, too. expressed use of classes in > [web2py: > > > > 32128]. > > > > a class-based MVC? like > > > > in plugins/myPlugin.py, > > > > class MyPlugin(Plugin): > > > > def model(...): > > > > ... > > > > def cotroller(...): > > > > ... > > > > def view(...): > > > > ... > > > > > > an application uses it as, e.g., > > > > in models/mydb.py, > > > > myP = Plugin.MyPlugin() > > > > ... do something useful with myP.model(...) ... > > > > in controllers/mycntl.py > > > > ... do something useful with myP.cotroller(...) ... > > > > in views/mycntl.html, > > > > ... do something useful with myP.view(...) ... > > > > > > * note myP.view() is not to output to browser but to input to views/ > > > > mycntl.html. > > > > * the plugins directgory can be anywhere in the path and imported. > > > > * as long as used/executed in non gpl applications, plugins need not > > > > be gpl licensed if gpl codes are not used/imported. > > > > * system plugins are in web2py/plugins (gpl) > > > > * application-shared plugins are in web2py/applications/plugins (gpl > > > > or non gpl) > > > > * application-specific plugins are in web2py/applications/myApp/ > > > > plugins (follow myApp's license) > > > > * plugins codes are copied and managed thru appadmin. > > > > * appadmin may not modify plugin codes. > > > > > > * all the above can be done without changing web2py or breaking its > > > > backward compatibility. > > > > * forgive me it's just contemplation, not implementation. > > > > > > recently, trying to meet the needs of a customer, i looked for a CMS > > > > with simple shop functionalities and found ezPublish(http://ez.no) > > > > interesting. learned that it's a quite elaborate accumulation of lots > > > > of work over 10 years by volunteers and companies. their site showed > > > > celebrating its 10th anniversary in a conference with over 250 people > > > > (http://www.youtube.com/watch?v=je6CqRWjwfo). its codes are based on > > > > components (http://ezcomponents.org), and structured with libraries, > > > > extensions, packages, etc. its slogan is "share your information". i > > > > think its framework's elaborate structuring of codes helped it to > > > > evolve to include lots of developers/users/companies. its learning > > > > curve is still rather steep for me, and i'm sure they'd do better if > > > > they have another chance to restructure. with the passion/power/ > > > > prowess (and with Python) in this community, web2py has a good > > > > opportunity to do better than others. > > > > > > it's nice to dream attending a web2py conference, whether online of > > > > offline, in some years, to share information and celebrate the > > > > accomplishment by web2py developers/users. > > > > > > cheers, > > > > Teru > > > > > > > On Thu, Oct 22, 2009 at 2:58 PM, mr.freeze <nat...@freezable.com> > > > wrote: > > > > > > >> I see how it would be a performance hit to enumerate all of the > files > > > > >> in those folders. What about a compromise where all plugins live > in > > > > >> one subfolder so we get the separation. Thinking out loud: > > > > > > >> applications > > > > >> --myapp > > > > >> ----plugins > > > > >> ------models > > > > >> --------plugin1.py > > > > >> --------plugin2.py > > > > >> ------views > > > > >> --------plugin1_index.html > > > > >> --------plugin2_index.html > > > > >> ------controllers > > > > >> --------plugin1.py > > > > >> --------plugin2.py > > > > >> etc... > > > > > > >> Do you think plugins should be accessible by URL outside of their > > > > >> parent app or just take parameters and render html? Also, > is/should > > > > >> there be a mechanism to apply auth to a plugin? > > > > > > >> On Oct 22, 1:48 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > > >> > One issue is models: > > > > > > >> > Let's say we have a normal model > > > > >> > models/db.py > > > > >> > and two plugin models in > > > > >> > plugins/p1/models/a.py > > > > >> > plugins/p1/models/x.py > > > > >> > plugins/p2/models/e.py > > > > > > >> > In which order should they be executed? whatever order we use we > > > would > > > > >> > have to merge the results of multiple listdir and then sort > them. > > > > >> > Takes some extra time. Now that everything is one folder things > are > > > > >> > straightforward. > > > > > > >> > Another issue is controllers? What would be the url for a > function > > > > >> > index in the controller below? > > > > > > >> > plugins/p3/controllers/default.py > > > > > > >> > Mind that we cannot break backward compatibility! > > > > > > >> > Massimo > > > > > > >> > On Oct 22, 1:38 pm, "mr.freeze" <nat...@freezable.com> wrote: > > > > > > >> > > That's not as limiting as I thought at least. Did you already > try > > > the > > > > >> > > sub-app approach and hit obstacles or is it something that > might > > > be > > > > >> > > worth prototyping so we can compare > > > performance/benefits/drawbacks? > > > > > > >> > > On Oct 21, 7:20 pm, mdipierro <mdipie...@cs.depaul.edu> > wrote: > > > > > > >> > > > Yes you would be limited to one model file, one controller > file > > > but as > > > > >> > > > many views as you have actions and as many modules and > static > > > files as > > > > >> > > > you need. > > > > > > >> > > > On Oct 21, 6:08 pm, "mr.freeze" <nat...@freezable.com> > wrote: > > > > > > >> > > > > Man oh man! I've been at a SharePoint conference all day > (hey, > > > I have > > > > >> > > > > to make money!) so I'm still sifting through all of the > > > discussion but > > > > >> > > > > I have another question: With the current implementation > > > plugins would > > > > >> > > > > be limited to one view, one controller, one model, etc., > > > because of > > > > >> > > > > the naming convention, correct? If so, do you think this > will > > > be too > > > > >> > > > > constraining? > > > > > > >> > > > > On Oct 21, 11:39 am, mdipierro <mdipie...@cs.depaul.edu> > > > wrote: > > > > > > >> > > > > > Physically plugins are not in the own folder because it > > > would make > > > > >> > > > > > web2py very clunky, it would have to search for plugins > in > > > the folder > > > > >> > > > > > structure. > > > > > > >> > > > > > Logically the are listed as separate. > > > > > > >> > > > > > On Oct 21, 11:16 am, "mr.freeze" <nat...@freezable.com> > > > wrote: > > > > > > >> > > > > > > I like how the plugin system is shaping up but have > one > > > question about > > > > >> > > > > > > the folder structure. It seems more manageable to > > > structure it like > > > > >> > > > > > > this: > > > > > > >> > > > > > > applications > > > > >> > > > > > > -- my app > > > > >> > > > > > > ---- models > > > > >> > > > > > > ---- views > > > > >> > > > > > > ---- controllers > > > > >> > > > > > > ---- plugins > > > > >> > > > > > > ------ myplugin > > > > >> > > > > > > -------- models > > > > ... > > > > read more » > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
