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 > > >> > > > > > > -------- views > > >> > > > > > > -------- controllers > > > > >> > > > > > > This way a plugin would basically be a sub-app, making it > easier to > > >> > > > > > > install/uninstall/upgrade and could also have multiple > models/views/ > > >> > > > > > > controllers. I remember some discussion about it but > can't remember > > >> > > > > > > what the reasons against it were. > > > > >> > > > > > > On Oct 21, 10:18 am, mdipierro <mdipie...@cs.depaul.edu> > wrote: > > > > >> > > > > > > > The new web2py in trunk (1.68.2) also contains an > improved > > >> > > > > > > > experimental solution for plugins. > > >> > > > > > > > Here is a new video about it > > > > >> > > > > > > >http://www.vimeo.com/7182692 > > > > >> > > > > > > > It includes suggestions from various people but I am > sure it still > > >> > > > > > > > needs a lot of work. Anyway, give it a try and let us > know what else > > >> > > > > > > > would you expect from a plugin system. > > > > >> > > > > > > > The interface for uploading/downloading plugins is > missing, among > > >> > > > > > > > other things. > > > > >> > > > > > > > Massimo- Hide quoted text - > > > > >> > > > > > - Show quoted text -- Hide quoted text - > > > > >> > > > - Show quoted text -- Hide quoted text - > > > > >> > - Show quoted text - > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
