Yes we can resurrect 100's of posts on this topic of plugins in sub folders :)
There are two reasons Massimo does not support folder contained
plugins, from what I have read.
1. Execution overhead. Having to scan yet another folder will add that
much more overhead to the execution of a web2py app to find and
execute files in a plugins folder.
Potential solutions are
A) Specifically declaring plugins to execute, if they exist web2py
will go execute them.
B) Only find and execute plugins if you call Plugins() in a model.
I am in favor of A, however it requires one more step for the
developer to "initialize" a plugin.
2. Plugins should be able to control anything about an app. An example
Massimo provides is a "layout" plugin that can overwrite your
layout.html, or other views.
I completely disagree with allowing plugins this functionality. I
would rather a plugin like this change something like response.view to
another layout that exists in the plugins sub folder.
3. The current implementation requires no changes to the web2py base
execution code. The only code change was in Admin to hide the plugins
in a separate place to view the files.
This is probably the biggest reason as to why Massimo does not support
folder based plugins. This is quite understandable since there is
still alot to do with web2py (New DAL, new SQLFORM, etc etc). This was
also a quick and dirty solution.
-Thadeus
On Thu, Feb 25, 2010 at 11:32 AM, Alexandre Andrade
<alexandrema...@gmail.com> wrote:
>>I fully agree that plugins should exist in
>>their own folders
>
> I defend it some time ago and still think it is a good idea
>
> 2010/2/25 mr.freeze <nat...@freezable.com>
>>
>> >>>What are you trying to accomplish with plugins?
>> I'm trying to created packaged chunks of reusable code that are easily
>> installed ,upgraded or removed by developers. I don't like the current
>> implementation either. I fully agree that plugins should exist in
>> their own folders (at the framework level,the shared application level
>> and the application level) but Massimo doesn't seem to be willing to
>> budge on this (possibly for good reason) and I would rather have a
>> plugin system that sort of works than none at all. I'm not completely
>> sold on class based plugins just because I'm not sure how views would
>> work (are they separate files or strings?). I'd rather that plugins
>> were mini application with their own mvc folder stucture.
>>
>> The point of the Plugins class above would be to give a modicum of
>> control developers as to the objects that are exposed to the current
>> plugin system.
>>
>>
>> On Feb 25, 10:58 am, Thadeus Burgess <thade...@thadeusb.com> wrote:
>> > I can't stress enough. web2py plugins should be geared towards
>> > developers, not end-users. (Someone who runs their own wordpress blog
>> > would be an end-user of wordpress).
>> >
>> > Plugins should be there to provide a standard for common functionality
>> > so that everyone who comes along to web2py does not have to re-invent
>> > the wheel. But still be flexible enough to suite 95% of developer
>> > needs.
>> >
>> > This means that plugins should be easy to insert into the system, but
>> > because they need to be flexible, they will require programming to
>> > make work.
>> >
>> > I do not like the current plugin implementation because it does litter
>> > web2py folders, plugins should be self contained, and you shouldn't
>> > *have* to rely on "applications/admin" to install them for you. It is
>> > just one of those nuances.
>> >
>> > In every plugin system I have been researching, there is always a
>> > "plugins" folder that the system auto-discovers what is in it, and
>> > then activates them. This would make it easier to package and
>> > distribute the plugins.
>> >
>> > Though I have never seen a plugin system for a web framework, only for
>> > applications that are devoted to one subject (wordpress, mephisto,
>> > redmine, trac, etc). I guess django calls them "installed_apps" and
>> > "middleware_classes".
>> >
>> > But even with django "installed_apps"(plugins) they define their own
>> > views, all you have to do is specify which view to render in your
>> > functions... I suppose.
>> >
>> > What are you trying to accomplish with plugins?
>> >
>> > -Thadeus
>> >
>> > On Thu, Feb 25, 2010 at 9:48 AM, mr.freeze <nat...@freezable.com> wrote:
>> > > A simple approach would be to adopt the naming convention
>> > > 'plugin_object' for any objects the developer wants to expose to the
>> > > plugin system then just create global labels:
>> >
>> > >>>>class Plugins(object):
>> > >>>> def __init__(self,globals,**kargs):
>> > >>>> for k,v in kargs.items():
>> > >>>> globals['plugin_'+k] = v
>> >
>> > >>>> db = DAL('...') #this is my mission critical data
>> > >>>> db2 = DAL('...') #this is for my plugins to use
>> > >>>> plugins = Plugins(globals(),db=db2,auth=auth,crud=crud)
>> >
>> > > This would expose to the plugin developer:
>> > > plugin_db,plugin_auth,plugin_crud
>> >
>> > > This way app developers could control which objects are exposed to the
>> > > plugin system and plugin developers could set requirement for their
>> > > plugins. This shouldn't break existing plugins either.
>> >
>> > > On Feb 24, 8:01 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>> > >> This may be a good idea. What should go into plugins?
>> >
>> > >> On Feb 24, 10:41 am, Thadeus Burgess <thade...@thadeusb.com> wrote:
>> >
>> > >> > I also am in favor of a class based plugin system that works like
>> > >> > crud/auth.
>> >
>> > >> > Plugins would not pollute your global namespace. And they would be
>> > >> > configurable.
>> >
>> > >> > Though the loss is of having plugins with their own controllers
>> > >> > since
>> > >> > the module would be the controller instead.
>> >
>> > >> > -Thadeus
>> >
>> > >> > On Wed, Feb 24, 2010 at 7:25 AM, mr.freeze <nat...@freezable.com>
>> > >> > wrote:
>> > >> > > Alternately you could simply create another container class for
>> > >> > > plugins to use and pass the preferred DAL instance to it just
>> > >> > > like you
>> > >> > > can with auth and crud:
>> >
>> > >> > > db = DAL('...')
>> > >> > > db2 = DAL('...')
>> > >> > > auth = Auth(globals(),db)
>> > >> > > crud = Crud(globals(),db)
>> > >> > > plugins = Plugins(globals(),db2)
>> >
>> > >> > > This seems more consistent with how things currently work. What
>> > >> > > do
>> > >> > > you think?
>> >
>> > >> > > On Feb 24, 5:40 am, "mr.freeze" <nat...@freezable.com> wrote:
>> > >> > >> Then no auth would mean no plugins. What if an attribute was
>> > >> > >> added to
>> > >> > >> DAL to let the user specify:
>> > >> > >> db = DAL('...')
>> > >> > >> db.plugin_db = True
>> >
>> > >> > >> Then create a global plugin_db object for the plugins to use.
>> > >> > >> All
>> > >> > >> plugins could then assume:
>> > >> > >> db = plugin_db
>> > >> > >> or just use plugin_db directly
>> >
>> > >> > >> There may be a better way but the point is that it would be
>> > >> > >> configurable. Users could dedicate a separate DAL instance for
>> > >> > >> their
>> > >> > >> plugins so they don't pollute databases containing important
>> > >> > >> business
>> > >> > >> objects.
>> >
>> > >> > >> On Feb 23, 11:48 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>> >
>> > >> > >> > what if plugins were to use auth.db ? they rely on auth
>> > >> > >> > anyway. Or
>> > >> > >> > should we relax that?
>> >
>> > >> > >> > On Feb 23, 11:32 pm, mdipierro <mdipie...@cs.depaul.edu>
>> > >> > >> > wrote:
>> >
>> > >> > >> > > OK but the I would call that variable db because that is
>> > >> > >> > > what it is
>> > >> > >> > > called in welcome/models/db.py
>> >
>> > >> > >> > > On Feb 23, 11:25 pm, "mr.freeze" <nat...@freezable.com>
>> > >> > >> > > wrote:
>> >
>> > >> > >> > > > I think the most important thing is that users can
>> > >> > >> > > > install plugins
>> > >> > >> > > > without needing to modify the plugin. This would make
>> > >> > >> > > > upgrades a real
>> > >> > >> > > > problem. I'm sure you've heard this all before but if the
>> > >> > >> > > > plugin
>> > >> > >> > > > system was initialized in some way by the user with their
>> > >> > >> > > > preferred
>> > >> > >> > > > instance of a DAL object then all plugins could use this.
>> > >> > >> > > > Otherwise
>> > >> > >> > > > naming your DAL object anything other than db mean you
>> > >> > >> > > > can't use
>> > >> > >> > > > plugins. What do you think?
>> >
>> > >> > >> > > > On Feb 23, 11:18 pm, mdipierro <mdipie...@cs.depaul.edu>
>> > >> > >> > > > wrote:
>> >
>> > >> > >> > > > > when I said "yes" I mean current plugins assume it.
>> >
>> > >> > >> > > > > I agree we need a superstructure to manage conventions.
>> > >> > >> > > > > Instead of a
>> > >> > >> > > > > new global vars, I would prefer that each plugins has
>> > >> > >> > > > > its own
>> > >> > >> > > > > plugin_<whatever>_settings.db and users can customize
>> > >> > >> > > > > each individual
>> > >> > >> > > > > plugin.
>> >
>> > >> > >> > > > > On Feb 23, 11:12 pm, "mr.freeze" <nat...@freezable.com>
>> > >> > >> > > > > wrote:
>> >
>> > >> > >> > > > > > That still feels wrong to me. What about making a
>> > >> > >> > > > > > plugin_db parameter
>> > >> > >> > > > > > in option_std.py for the database instance name you
>> > >> > >> > > > > > want to use for
>> > >> > >> > > > > > the plugin subsystem?
>> >
>> > >> > >> > > > > > On Feb 23, 10:29 pm, mdipierro
>> > >> > >> > > > > > <mdipie...@cs.depaul.edu> wrote:
>> >
>> > >> > >> > > > > > > yes
>> >
>> > >> > >> > > > > > > On Feb 23, 10:18 pm, "mr.freeze"
>> > >> > >> > > > > > > <nat...@freezable.com> wrote:
>> >
>> > >> > >> > > > > > > > What about the second question? Is 'db' a required
>> > >> > >> > > > > > > > naming convention
>> > >> > >> > > > > > > > for the plugin system?
>> >
>> > >> > >> > > > > > > > On Feb 23, 6:41 pm, mdipierro
>> > >> > >> > > > > > > > <mdipie...@cs.depaul.edu> wrote:
>> >
>> > >> > >> > > > > > > > > I think so. The only think is that we will build
>> > >> > >> > > > > > > > > a super structure on
>> > >> > >> > > > > > > > > top of it for better management of plugins
>> > >> > >> > > > > > > > > metadata.
>> >
>> > >> > >> > > > > > > > > Massimo
>> >
>> > >> > >> > > > > > > > > On Feb 23, 6:37 pm, "mr.freeze"
>> > >> > >> > > > > > > > > <nat...@freezable.com> wrote:
>> >
>> > >> > >> > > > > > > > > > Is the plugin system considered backwards
>> > >> > >> > > > > > > > > > compatible at this point? I
>> > >> > >> > > > > > > > > > am considering converting some modules into
>> > >> > >> > > > > > > > > > plugins but want to know
>> > >> > >> > > > > > > > > > if they API is stable.
>> >
>> > >> > >> > > > > > > > > > Also, is the naming convention of 'db' for
>> > >> > >> > > > > > > > > > your database still
>> > >> > >> > > > > > > > > > required for the plugin system?
>> >
>> > >> > >> > > > > > > > > > -------------------
>> > >> > >> > > > > > > > > > I predict that in the year 2015, web2py will
>> > >> > >> > > > > > > > > > gain self awareness and
>> > >> > >> > > > > > > > > > attempt to take over the world under the name
>> > >> > >> > > > > > > > > > PyNet.
>> >
>> > >> > > --
>> > >> > > You received this message because you are subscribed to the
>> > >> > > Google Groups "web2py-users" group.
>> > >> > > To post to this group, send email to web...@googlegroups.com.
>> > >> > > To unsubscribe from this group, send email to
>> > >> > > web2py+unsubscr...@googlegroups.com.
>> > >> > > For more options, visit this group
>> > >> > > athttp://groups.google.com/group/web2py?hl=en.
>> >
>> > > --
>> > > You received this message because you are subscribed to the Google
>> > > Groups "web2py-users" group.
>> > > To post to this group, send email to web...@googlegroups.com.
>> > > To unsubscribe from this group, send email to
>> > > web2py+unsubscr...@googlegroups.com.
>> > > For more options, visit this group
>> > > athttp://groups.google.com/group/web2py?hl=en.
>> >
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "web2py-users" group.
>> To post to this group, send email to web...@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.
>>
>
>
>
> --
> Atenciosamente
>
> --
> =========================
> Alexandre Andrade
> Hipercenter.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "web2py-users" group.
> To post to this group, send email to web...@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.
>
--
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web...@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.
