In my view web2py level plugins open the doors  to a lot of
portability and incompatibility problems. That is what web2py tries to
avoid by making every app complete.

On Mar 13, 11:37 am, Thadeus Burgess <thade...@thadeusb.com> wrote:
> When would an app level plugin get executed?
>
> What If I have code I want to execute AFTER plugins?
>
> What if I need a plugin to execute after another plugin, how do you
> control this?
>
> -Thadeus
>
> On Sat, Mar 13, 2010 at 9:25 AM, mdipierro <mdipie...@cs.depaul.edu> wrote:
> > If I understand you are asking for a web2py level plugin system vs an
> > app level plugin system. This has nothing to do with relocation of
> > plugins under an app subfolder. Am I correct?
>
> > On Mar 13, 5:36 am, selecta <gr...@delarue-berlin.de> wrote:
> >> If it is possible I am in favor of relocating plug-ins to an extra
> >> folder since this would ease my development a lot.
> >> I develop plug-ins for multiple apps (e.g. a tracker plug-in) and I
> >> use version control. Right now I have to decide which project is
> >> taking control of developing the plug-in. It works for now but I will
> >> soon be at a point where I have two separate project with different
> >> people that both should help to develop the same plug-ins. An extra
> >> folder for the plugin would allow the plug-in to be under independent
> >> version control from the rest of the application.
>
> >> Other than that I really like the current plug-in system. It is just
> >> like developing a normal web2py app, simple, nothing new! And if I
> >> read the branding discussion right this is what everybody (including
> >> me) loves about web2py. I would strongly advise against any solution
> >> that requires me to gain extra knowledge to create plug-ins.
>
> >> On Mar 12, 7:08 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> >> > I think this is a different issue. If you relocate plugins but you
> >> > still have all code in plugins/<name>/models/<something>.py then they
> >> > would work no differently than now (they would be executed in
> >> > alphabetical order with the plugin name). To do what you ask you would
> >> > have to put plugin code in modules and import them (something you can
> >> > already do). The problem is that you would have to be very explicit
> >> > and import plugins. Installing them would not be enough and that I do
> >> > not like (at least not in the general case).
>
> >> > On Mar 12, 10:36 am, Thadeus Burgess <thade...@thadeusb.com> wrote:
>
> >> > > If all plugins are designed to be class-like, then your example of
> >> > > plugins just need to inherit.
>
> >> > > The only reason I would be in support for logically changing the
> >> > > location of plugins is the one of dependencies.
>
> >> > > Meaning, if you have to specify to web2py when to load a plugin, and
> >> > > in what order... it can handle the dependencies and execute the needed
> >> > > ones first.
>
> >> > > Dependencies are not hard, its quite simple to write some code to do
> >> > > this (as I do in py2jquery to handle javascript dependencies). As
> >> > > Massimo said, the difficulty is in the bytecode compiling.
>
> >> > > I am not convinced there will be any overhead (the slowdown is the 99%
> >> > > database any ways). It just means web2py will need to be "smarter"
> >> > > about where stuff is.
>
> >> > > -Thadeus
>
> >> > > On Fri, Mar 12, 2010 at 8:52 AM, mdipierro <mdipie...@cs.depaul.edu> 
> >> > > wrote:
> >> > > > The problem with framework level plugins is that if you pack the app
> >> > > > and unpack somewhere else then it will not work without the 
> >> > > > "framework
> >> > > > level" plugin installed separately. I do not think that is something
> >> > > > to encourage. Moreover different apps may reply on different versions
> >> > > > of the plugin and/or need different configuration.
>
> >> > > > Anyway there are two things that can be done at framework level: 1)
> >> > > > put models in web2py/site-packages 2) framework level models can be
> >> > > > defined in modules and put there also; 3) framework level views and
> >> > > > static file can be stored in a new app designed at hoc for this
> >> > > > purpose and other app can use them too.
>
> >> > > > Massimo
>
> >> > > > On Mar 12, 8:36 am, Alex Fanjul <alex.fan...@gmail.com> wrote:
> >> > > >> Just to clarify it:
>
> >> > > >> Do we able to conservate my app (rewrited/extended) auth 
> >> > > >> module/model,
> >> > > >> working alongside "superAuth" thadeus plugin, discarding your 
> >> > > >> framework
> >> > > >> plugin and system Auth default one?
> >> > > >> Alex
>
> >> > > >> El 12/03/2010 15:31, Alex Fanjul escribi :
>
> >> > > >> > Ok Massimo,
> >> > > >> > I agree with you in it makes no sense to rewrite a lot of web2py 
> >> > > >> > code.
>
> >> > > >> > Apart from that argument in favor, there is another I don't know 
> >> > > >> > if it
> >> > > >> > would be satisfied right now with plugin_name.py convention:
>
> >> > > >> > -Imagine you write a *framework level plugin* to subsitute auths 
> >> > > >> > (or
> >> > > >> > whatever system feature) views/controllers/models.
> >> > > >> > -Imagine thadeusb write another *application level plugin* to do 
> >> > > >> > the
> >> > > >> > same called "superAuth"
> >> > > >> > -Imagine I write an application with an *only modules* extended 
> >> > > >> > auth
> >> > > >> > service with some more fields and stuffs.
>
> >> > > >> > Do we able to conservate my app rewrited/extended auth 
> >> > > >> > module/model
> >> > > >> > over "superAuth" thadeus plugin, discarting system default one?
>
> >> > > >> > Just thoughts,
> >> > > >> > Alex
>
> >> > > >> > El 12/03/2010 14:01, mdipierro escribi :
> >> > > >> >> The location of plugins is not a backward compatibility issue. 
> >> > > >> >> From
> >> > > >> >> that point of view, we could relocate plugin files.
> >> > > >> >> The reason I do not want to do is that it is an implementation 
> >> > > >> >> issue
> >> > > >> >> that requires rewriting a lot of web2py code (particularly for 
> >> > > >> >> the
> >> > > >> >> bytecode-compile functionality), that will make web2py slower, 
> >> > > >> >> not
> >> > > >> >> faster, and does not seem to add any new feature (except the
> >> > > >> >> relocation itself).
> >> > > >> >> The only argument I have heard in favor of relocation is in fact 
> >> > > >> >> that
> >> > > >> >> code will look cleaner with a new plugins location. I do not 
> >> > > >> >> disagree
> >> > > >> >> but to users of admin things will look exactly the same (because 
> >> > > >> >> of
> >> > > >> >> the logical location according to admin is already the one you
> >> > > >> >> suggest), to users of the shell models would be scattered and it 
> >> > > >> >> would
> >> > > >> >> be more difficult to identify order of execution, and you will 
> >> > > >> >> get a
> >> > > >> >> little bit of cleanness is user code at the expense of lots of 
> >> > > >> >> dirt in
> >> > > >> >> web2py code (lots of if statements to find out what is where).
>
> >> > > >> >> I will not do it. If somebody wants to write a fully working 
> >> > > >> >> proof of
> >> > > >> >> concept implementation to demonstrate that 1) it is not slower; 
> >> > > >> >> 2) it
> >> > > >> >> can be done without too much extra complexity in web2py source, 
> >> > > >> >> I may
> >> > > >> >> take the patch.
>
> >> > > >> >> Massimo
>
> >> > > >> >> On Mar 12, 4:39 am, Alex Fanjul<alex.fan...@gmail.com>  wrote:
> >> > > >> >>> Hi Massimo,
>
> >> > > >> >>> I haven't said that plugins should have to depend on others, 
> >> > > >> >>> but they
> >> > > >> >>> should be able to access/play with others to make a trully 
> >> > > >> >>> plugins
> >> > > >> >>> central network, the dependencies are resoluble at highly level 
> >> > > >> >>> with an
> >> > > >> >>> exposed convention API like:
>
> >> > > >> >>> plugin_most_active_users.requires=['comments-1.x.x', 
> >> > > >> >>> 'auth-2.x.x']
> >> > > >> >>> plugins['tag_cloud'].requires =['tags-1.2.x']
>
> >> > > >> >>> Its only an idea.
>
> >> > > >> >>> The backward compatibility breaks with the heritance folder 
> >> > > >> >>> structure
> >> > > >> >>> (as I though you said), isn't it?
>
> >> > > >> >>> *App Level: (example: plugin for commets)*
> >> > > >> >>> web2py/applications/my_app/plugins/my_plugin/modules/module*.py
> >> > > >> >>> web2py/applications/my_app/plugins/my_plugin/views/views*.py
> >> > > >> >>> web2py/applications/my_app/plugins/my_plugin/controllers/controllers*.py
>
> >> > > >> >>> web2py/applications/my_app/plugins/my_plugin/static/statics*.jpg
>
> >> > > >> >>> *Framework Level (example: plugin for ckeditor Editor, or last 
> >> > > >> >>> Wes
> >> > > >> >>> James
> >> > > >> >>> coda helper)*
> >> > > >> >>> web2py/plugins/my_plugin/controllers/controllers*.py
> >> > > >> >>> web2py/plugins/my_plugin/views/views*.py
>
> >> > > >> >>> The way to ordering load is down-to-up I think, like kohana
> >> > > >> >>> does:http://docs.kohanaphp.com/general/modules,http://v3.kohanaphp.com/gui....
>
> >> > > >> >>> Also it's very important the hooks
> >> > > >> >>> <http://docs.kohanaphp.com/general/events> &  events
> >> > > >> >>> <http://docs.kohanaphp.com/general/events>  system, as both of 
> >> > > >> >>> you
> >> > > >> >>> (thadeus, Massimo) talked at the end of the chat:
>
> >> > > >> >>> There is no calling for new Cache system at all...just was an
> >> > > >> >>> example...
>
> >> > > >> >>> regards,
> >> > > >> >>> Alex
>
> >> > > >> >>> El 12/03/2010 5:26, mdipierro escribi :
>
> >> > > >> >>>> I agree with most of what you say.
> >> > > >> >>>> 99.99% of apps use a single database and so will plugins. This 
> >> > > >> >>>> is
> >> > > >> >>>> because they needs auth to do anything meaningful.
> >> > > >> >>>> I do not think it is a good idea to have plugins that depend 
> >> > > >> >>>> on each
> >> > > >> >>>> other. dependencies are a mess to manage. In any language and 
> >> > > >> >>>> any OS I
> >> > > >> >>>> ever used. plugins with dependencies are cause for trouble.
> >> > > >> >>>> But I agree that we may build groups of plugins that cooperate 
> >> > > >> >>>> for
> >> > > >> >>>> some specific tasks (like share access to certain tables and or
> >> > > >> >>>> certain web services). This will happen for plugins geared 
> >> > > >> >>>> toward
> >> > > >> >>>> specific types of apps so we should not over-engineer it now.
> >> > > >> >>>> I do not think we need a 2.0 for those things that you asked. 
> >> > > >> >>>> We will
> >> > > >> >>>> get there in small steps and, at this point, I do not see why 
> >> > > >> >>>> any of
> >> > > >> >>>> those improvements should be inconsistent with backward 
> >> > > >> >>>> compatibility.
> >> > > >> >>>> What's your wish list for cache? I never heard anybody calling 
> >> > > >> >>>> for a
> >> > > >> >>>> new cache system.
> >> > > >> >>>> Massimo
> >> > > >> >>>> On Mar 11, 9:02 pm, Alex Fanjul<alex.fan...@gmail.com>    
> >> > > >> >>>> wrote:
> >> > > >> >>>>> Very interesting and constructive IRC meeting, congrats to 
> >> > > >> >>>>> all. After
> >> > > >> >>>>> reading all text
>
> ...
>
> read more »

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

Reply via email to