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