I have these questions for even normal plugins. What If I make a plugin called `plugin_aptimizor`, that iterates through my db and creates an optimized search index.
So later I have `plugin_comments`, but oh, I want my comments to be part of this search index... but the search index plugin does not know about this. It really sucks to then have to edit the name of the plugin_aptimizor to make sure it executes last. -Thadeus On Sat, Mar 13, 2010 at 12:03 PM, mdipierro <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> >> > > 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 <[email protected]> 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<[email protected]> 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<[email protected]> >> >> > > >> >>>> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
