>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<web2py%2bunsubscr...@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<web2py%2bunsubscr...@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<web2py%2bunsubscr...@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.
