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.
