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