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 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.
