how about? models/plugin_name/pre.py models/plugin_name/call.py models/plugin_name/post.py
where pre is called before any other model, post after all models and call only when a plugin action is called. the packaging would still work. We would need to add a couple of line in gluon/compileapp/run_models_in On Nov 8, 1:21 am, Thadeus Burgess <thade...@thadeusb.com> wrote: > Meaning the only thing that needs to be changed is the admin plugin packing. > > -Thadeus > > On Sun, Nov 8, 2009 at 1:21 AM, Thadeus Burgess <thade...@thadeusb.com>wrote: > > > Or we could throw yet another naming convention into the mix. > > > plugins that need pre-execution get a 0 appended before the name. > > > plugins that need post-execution, get a z appended > > > 0_plugin_comments.py > > z_plugin_layouts.py > > > -Thadeus > > > On Sun, Nov 8, 2009 at 1:11 AM, Thadeus Burgess > > <thade...@thadeusb.com>wrote: > > >> Maybe execute them in alpha order. Plug-ins should not depend on other > >> plug-ins? > > >> -Thadeus > > >> On Sun, Nov 8, 2009 at 1:00 AM, mdipierro <mdipie...@cs.depaul.edu>wrote: > > >>> It seems to me dispatching only affects controllers and the current > >>> mechanism works well for controllers. > > >>> The problem is models. As you say plugin models should be able to say > >>> "execute this before everything else" and "execute that after > >>> everything else". The problem is what happens when two plugins say > >>> "execute this before everything else"? I do not know how to solve this > >>> problem. > > >>> Of course you can have plugins completely defined in module files and > >>> you can import them explicitly in your code where needed. To me this > >>> is a special type of plugin. > > >>> Massimo > > >>> On Nov 7, 8:52 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > >>> > I have a solution, but you might not like it. > > >>> > web2py needs a dedicated plugin subsystem. > > >>> > With a dedicated plugin dispatcher, things like this can be controlled, > >>> a > >>> > plug-in can specify a setting PRE_MODEL/POST_MODEL that says "execute > >>> this > >>> > plugin before/after models are executed". > > >>> > I still don't want plug-ins assuming my database... yes I could edit > >>> the > >>> > plug-in, but your whole thing is about having plug-ins that you don't > >>> have > >>> > to edit! But really it comes down to the fact that I am a software > >>> engineer, > >>> > and I like to be in control as much as possible. > > >>> > -Thadeus > > >>> > On Sat, Nov 7, 2009 at 7:14 PM, mdipierro <mdipie...@cs.depaul.edu> > >>> wrote: > > >>> > > the current plugin mechanism has a problem. There is no way to > >>> specify > >>> > > what should be executed before the other models and what after the > >>> > > other models. They are executed in alphabetical order as any other > >>> > > model. This problem needs a solution. > > >>> > > Executing all plugins before models is not a good solution because > >>> > > some plugins may need a model. Moreover some plugin may act on > >>> > > existing models. > > >>> > > I do not have a solution to this problem. > > >>> > > Plugins should assume a db (unless they define their own). You may > >>> not > >>> > > call it "db" but they should be able to reference it. > > >>> > > Some plugins may need auth, crud or service (unless they define their > >>> > > own). > > >>> > > Ideally plugins should expose their own configuration page > >>> (accessible > >>> > > only to admin) and should perhaps store configuration settings in a > >>> > > file. > > >>> > > Massimo > > >>> > > On Nov 7, 6:11 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > >>> > > > Love the module Mr Freeze. > > >>> > > > I have some same questions about how plug-ins would find out about > >>> > > certain > >>> > > > things in your app. > > >>> > > > Say I want to write a plugin_ratingsystem.py, how would I pass > >>> settings > >>> > > > along to the plug-in from my db.py? Since plug-in models get > >>> executed > >>> > > after > >>> > > > db.py. > > >>> > > > What about making it so any model plugin_<name>.py get executed > >>> first by > >>> > > > web2py, in alphabetical order of name. This way plug-ins can define > >>> > > classes > >>> > > > and be explicitly called for execution. > > >>> > > > I agree with Mr. Freeze. plug-ins should not assume db, auth, crud, > >>> > > etc... > >>> > > > etc... Perhaps plug-ins that use database should need to be > >>> explicitly > >>> > > > called > > >>> > > > plugin_comments.init(db=mydb, othersetting="hi") > > >>> > > > -Thadeus > > >>> > > > On Sat, Nov 7, 2009 at 4:59 PM, mr.freeze <nat...@freezable.com> > >>> wrote: > > >>> > > > > > I think plugins should assume db, auth, crud, mail, service. > >>> > > > > > Don't you do the same with your code? A plugin is nothing more > >>> than a > >>> > > > > > means to package and distribute your code. > > >>> > > > > I don't think code should ever assume anything. I used the > >>> instances > >>> > > > > since they are in the same model. If I were to make a module out > >>> of > >>> > > > > this it would take the instances as arguments. > > >>> > > > > > I think the plugin should assume db. I do not see a problem > >>> with > >>> > > > > > people editing the plugin anyway. > >>> > > > > > That could be a way to customize it. > > >>> > > > > Won't this make upgrading plugins a pain? You would have to go > >>> back > >>> > > > > through and edit every plugin that you modified before upgrade. > > >>> > > > > I'll probably just make a module since it will be more reusable. > >>> > > > > Thanks for checking it out. > > >>> > > > > On Nov 7, 4:47 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > >>> > > > > > On Nov 7, 4:06 pm, "mr.freeze" <nat...@freezable.com> wrote: > > >>> > > > > > > Hmmm...Interesting proposition. A couple of questions first: > > >>> > > > > > > 1) How will the plugin know what the instances of > >>> Auth,Crud,Mail > >>> > > and > >>> > > > > > > DAL are named? Are auth,crud,mail and db pretty much reserved > >>> words > >>> > > > > > > now? > > >>> > > > > > I think plugins should assume db, auth, crud, mail, service. > >>> > > > > > Don't you do the same with your code? A plugin is nothing more > >>> than a > >>> > > > > > means to package and distribute your code. > > >>> > > > > > > 2) How would I let the user decide which db to put the tables > >>> in if > >>> > > > > > > they have multiple? Do they have to edit the plugin? > > >>> > > > > > I think the plugin should assume db. I do not see a problem > >>> with > >>> > > > > > people editing the plugin anyway. > >>> > > > > > That could be a way to customize it. > > >>> > > > > > I do not exclude a more specialized plugin that assume more > >>> and/or > >>> > > > > > something different. > > >>> > > > > > > On Nov 7, 3:57 pm, mdipierro <mdipie...@cs.depaul.edu> > >>> wrote: > > >>> > > > > > > > I think this is nice. > > >>> > > > > > > > If you now call that files models/plugin_settings.py and if > >>> all > >>> > > > > tables > >>> > > > > > > > have a prefix plugin_settings_* > > >>> > > > > > > > then you can distribute it as a web2py.plugin.settings.py > > >>> > > > > > > > Massimo > > >>> > > > > > > > On Nov 7, 3:22 pm, "mr.freeze" <nat...@freezable.com> > >>> wrote: > > >>> > > > > > > > > I put this together to let non-developer admins manage > >>> settings > >>> > > > > > > > > through appadmin. It basically puts all settings that > >>> are > >>> > > string, > >>> > > > > > > > > int, double or boolean in the database. I would like > >>> feedback > >>> > > on > >>> > > > > the > >>> > > > > > > > > perils/merits of doing this. > > >>> > > > > > > > >http://www.web2pyslices.com/main/slices/take_slice/26 > > >>> > > > > > > > > Thanks! > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@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 -~----------~----~----~----~------~----~------~--~---
