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 2) some may expose more than one controller action 3) some will act on axisting db 4) some will have their own db 5) some will act on existing tables 6) some will define their own tables 7) some will keep those tables private 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. 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 -~----------~----~----~----~------~----~------~--~---
