I think for plugins to work, they should target a specific app (a CMS for example). Some may be more generic than others. I my specs I required the app to provide db, auth and crud as minimal requirements. If you use a db with another name, you can still use plugins but you will have to do something like
db=your_db On Oct 24, 2:20 pm, "mr.freeze" <nat...@freezable.com> wrote: > > Why? I think you have in mind a special type of plugin. I have in mind > > a more general one. What about a plugin that only contains a static > > file, for example an image of a js library? > > I don't see any way from the video to use a plugin without modifying > it, which makes it inherently unpluggable. In the video you are using > instances of db and crud in the comments pugin that may or may not > exist for all users. If the plugin system was initialized with these > then it would be generic for all plugins. > > On Oct 24, 1:05 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > On Oct 24, 12:34 pm, "mr.freeze" <nat...@freezable.com> wrote: > > > > Yes, that is another good example. I think all of the problems with > > > the sub-app approach are very solvable: > > > > 1) Portability and separation: > > > There needs to be a Plugin class that is instantiated like Auth with > > > database, globals, etc. It should be separated completely from LOAD. > > > This will let the user determine which database the plugin system will > > > use. > > > > plugin = Plugin(db,globals()) > > > Why? I think you have in mind a special type of plugin. I have in mind > > a more general one. What about a plugin that only contains a static > > file, for example an image of a js library? > > > > 2) Order of execution: > > > Plugins are not executed until they are called. Once a plugin is > > > called, it's models are executed in the same order that web2py > > > executes app models > > > Why limit to this case. If the models are to be executed ONLY when the > > plugin is called, define the model on top of the controller. Mind that > > by doing this you will not be able to access tables defined by the > > plugin from appadmin. > > > > 3) Plugin URL when in subfolder: > > > Plugins could be exposed in a similar fashion to Auth and Service > > > through an app controller. There would be a controller function that > > > serves plugins using request args. You could also call a load function > > > explicitly to render a plugin in a view. > > > > def plugins: > > > return plugin() > > > Plugin: appname/plugins/p3/controllers/default.py > > > URL:http://localhost:8000/appname/default/plugins/p3/default/ > > > Or manually passing your own args > > > {{=plugin.load("comments",f="index",ajax_trap=True)}} > > > > Basically, do it just like things are done in tools.py. Thoughts? > > > What you have in mind is not a plugin but a module, like gluon.tools > > is a module. With my proposals you can have plugins that contain only > > modules and they will work as you say. You will be able to create > > plugins that work the way you say, I just do not believe all types of > > plugins I have in mind fit in this scheme (layout plugins for > > example). > > > 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 -~----------~----~----~----~------~----~------~--~---
