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 at
http://groups.google.com/group/web2py?hl=en.
