On Wed, Oct 21, 2009 at 4:32 PM, mdipierro <mdipie...@cs.depaul.edu> wrote:
> > I want to add something to this. I envision many different types of > plugins and combinations thereof: > > 1) some plugin may expose a controller action > Do you mean a plugin may contain a controller? > 2) some may expose more than one controller action > A controller's interface may include controllers - what are the rules? Can it redirect to use an app view? Must it contain it's own matching views? How will this happen? > 3) some will act on axisting db > How will a plugin that is used by more than one app know the db? How will it prevent its own tables from accidentally conflicting with an apps? What are the needed rules / constraints for this? > 4) some will have their own db > How will a plugin's db be created? IN the case where manual creation is needed, how will plugin installation handle this? What is needed here? > 5) some will act on existing tables > How will data integrity be assured for such plugins? (I can think of a malicious plugin doing nasty things, or a sloppy one doing even worse)? > 6) some will define their own tables > In what db? What are the rules? How does the app now? How will the app know wich tables belong to the plugin? > 7) some will keep those tables private > Private from users? Private from app (how)? > 8) some will expose those tables to the rest of the app > > 9) some may just define a new helper or widget for forms > 10) some may just define a new layout > 11) some may just contain static files > 12) some my just contain python modules > 13) some may expose internal variables, for example to a CMS app > > So for me a plugin is not always an isolated entity. > I will not go on - this is an example, and I invite everyone from the community to consider the same sorts of questions, but "is not isolated" begs "is it modular?" and introduces all sorts of nasty potential problems due to coupling. This then begs the question - should it be a plugin? or a component (e.g. part of the app, and not pluggable, due to application coupling). This is a shopping list which needs some reasonable constraints first, I think, or it will not be implementable in any clean way. I think this list is still too fuzy, and needs to be made more crisp. It may be that we're talking about 2 or 3 separate "systems" here (e.g. plugin, and ....) Keep talking about it. - Yarko > > Some will only have models, some will only have controllers, some will > only have views, some will only have static files. Some will have all > of these. > > On Oct 21, 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. > > > > > 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. > > > > > 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. > > > > One again. This is not the end of the story. I welcome this > > discussion. I have been proven wrong before. :-( > > > > 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 -~----------~----~----~----~------~----~------~--~---
