On Oct 23, 4:09 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > The rationale is complex and it does not exclude that in future we > will have plugins with a different folder structure. But consider > layout plugins (http://web2py.com/layouts). They need to overwite > views/layout.html. They would not fit into the folder structure.
The whole issue with conflicts exists, I agree, but there are ways around it. One way would be to have a config file included with every plugin instructing web2py which file to use (plugin or your application) when there is a conflict. I think Pinax (django collection of apps) deals with this issue very nicely. > Also if a plugin were to define a function that was available to all > controllers, the model you propose would not work. This issue of designing a plugin system is not a simple one. I simply propose looking at django for inspiration, as their system works quite well (just look at the number of django-apps out there). I must say, though, that the solution you guys found works as a start to tackling this issue. Has anyone started a design wiki for this issue anywhere (google code, web2py wiki, etc)? > > For us plugins are just an application subset (this is discussed in > chapter 13 of the new book) but nothing exclude creating a plugins > folder, create plugins that install themselves in there, and a > plugins.py controller that delegates an action to a function defined > in a file in the plugins folder. > > Massimo My main argument for the framework to have a defined method to this, rather than having everyone find their own work-around, is so that I can release components of my webapp as plugins. > > On Oct 23, 5:59 pm, b00m_chef <r...@devshell.org> wrote: > > > > > I like web2py more than django because it has everything django has, > > but somehow I feel it was designed to contain those features from the > > get-go. In django everything feels like it was an after-thought, and > > the community feels extremely set in their ways to change anything. > > > One thing, thought, that I feel they got right in django was the > > separation of projects into apps. I was just wondering why web2py > > chose not to separate plugins more from the main application. I find > > it extremely ugly to have my application files be polluted by plugin > > files. I wish I could just easily blow-away my application without > > blowing away all the plugins with it, or vice-versa. Basically, if my > > plugin is more complicated than 1 file in each (model, controller, > > view), and I if I have more than 3 plugins installed, my application > > becomes a mess very quickly. This is especially a problem when you get > > to large apps that are built from many small plugins for various > > features... > > > Proposed directory structure: > > - "Application name" > > - Model > > - View > > - Controller > > - Static, etc... > > - Plugins > > - "Plugin name" > > - Model > > - View > > - Controller > > - Static, etc... > > > Note, this can also be done without changing everything in the way > > web2py does it right now, simply by including a symbolic link/shortcut > > to the plugins folder in the top-level model, controller, view, and > > static directories, to the plugins/plugin-name/model, view, > > controller, static folders... > > > Proposed directory structure: > > - "Application name" > > - Model > > - Shortcut to "Plugins" folder > > - View > > - Shortcut to "Plugins" folder > > - Controller > > - Shortcut to "Plugins" folder > > - Static, etc... > > - Shortcut to "Plugins" folder > > - Plugins > > - "Plugin name" > > - Model > > - View > > - Controller > > - Static, etc... > > > I find the Django model of Project -> apps a great organization > > system...in web2py it would be App -> plugins. > > > In other words, have a folder in each project/application called > > plugins, and in that folder have each plugin produce its own folder > > containing everything necessary for that app (directory structure > > would be identical to the main app/project directory structure)...in > > essence, it would be an application within an application. > > > Also, note that I had thought about simply having plugins be apps at > > the top level that can communicate with other apps, but that would not > > work if I want to package my application up and distribute it. > > > Conclusion: > > > Was there any reason this was not the directory structure chosen? > > Other than "We wanted to implement something quickly that is backwards > > compatible and requires least additional coding". I just wonder if the > > directory structure I propose could ever have enough support to be > > accepted (even if it doesn't happen in the next release). > > > Thank you for the great framework!!
