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 I have some comments: >> >>>>> - Most of the meeting (50% at least) was concerning about *how >> >>>>> many and >> >>>>> what databases should plugins have access to*...it seems the most >> >>>>> headache for all, BUT, I'm pretty sure that 99% of today real WEB >> >>>>> applications (and very complex ones) in world uses no more than 1 >> >>>>> database: think of Magento's, Elgg's, Zimbra's, Active Collab's, >> >>>>> Twitter's, OpenBravo's, Wordpress's, Drupal's, etc. All of them >> >>>>> use only >> >>>>> ONE database (maybe clustered, spreaded, mirrored, etc. but ONE), and >> >>>>> many of them has very complex plugins systems. The "problem" here, is >> >>>>> that with web2py its very simple and easy to create a new >> >>>>> database: just >> >>>>> do "db=DAL(...)"... and many times we are even "confusing" (in the >> >>>>> right >> >>>>> sense) databases with tables... A game for us: Tell me more than 2 >> >>>>> real >> >>>>> web applications using more than one database. A reflection: I >> >>>>> would be >> >>>>> very afraid if after installing 20 plugins (as I have in my latest >> >>>>> drupal installation) I bump into 20 (or 15 or 10 or even 5) new >> >>>>> databases in my phpmyadmin/pgadmin. Yea: be generic and assume all >> >>>>> posible cases... but.... >> >>>>> I think Thadeusb was in the right direccion in some >> >>>>> comments...asumming >> >>>>> a worst case of ONE shared db for plugins. moreover this would >> >>>>> simplified things, right? >> >>>>> - "Turicas: should a plugin access other plugins' data?" --> >> >>>>> "thadeusb: >> >>>>> Turicas: I would think no, because a plugin should be self >> >>>>> contained." >> >>>>> In this case I disagree, the plugins -for sure- should be able to >> >>>>> access >> >>>>> to other plugins data/functions, because as centralplugins grow >> >>>>> up, many >> >>>>> of them will be based on others to not reinvent the wheel, so *we >> >>>>> will >> >>>>> need a strong convention in exposing API for functions, objects, >> >>>>> etc.* >> >>>>> (think of a "plugin_most_active_users" based on thadeus >> >>>>> "plugin_commets"). >> >>>>> - Finally I believe that a "heritance folder convention" where you >> >>>>> can >> >>>>> override/extend parents functionality/skins/models like the great >> >>>>> kohana's plugin system (someone mentioned) is the best way to >> >>>>> achive a >> >>>>> "easy" and "comprensible" plugin system. Yes, that would suppose a >> >>>>> big >> >>>>> change and probably a backward compatible inflexion point, but as >> >>>>> Massimo said, talk me about functionallity not about implementation. >> >>>>> Concerning this, and to be honest I'm always thinking of a Massimo >> >>>>> annunce saying: "Web2py 2.0 Released: the new easier, faster and even >> >>>>> more powerful python web framework with new DAL, new Plugin >> >>>>> System, new >> >>>>> Cache System, new CSS/Form system, etc. (ops but without 1.x backwark >> >>>>> compatibility sorry)", but it's just a dream :-P >> >>>>> Is there any new IRC appointment planned? >> >>>>> Best regards, >> >>>>> Alex >> >>>>> PD: excuse me for my english (as always) >> >>>>> -- >> >>>>> Alejandro Fanjul Fdez. >> >>>>> alex.fan...@gmail.comwww.mhproject.org >> >>> -- >> >>> Alejandro Fanjul Fdez. >> >>> alex.fan...@gmail.comwww.mhproject.org >> >> -- >> Alejandro Fanjul Fdez. >> alex.fan...@gmail.comwww.mhproject.org > > -- > 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.
