I have thought about that but: - having a plugin folder means web2py would have to look for models in multiple places. It could me mimicked in admin (the developers should not see the plugin_* files under the [design] page but user a reparate plugin page where model/views/controllers/etc are organized by name. - Why change the programming model and use a class?
Massimo 2) having plugins like a class On Oct 1, 11:41 am, Yarko Tymciurak <[email protected]> wrote: > I generally like the concept, but am uncomfortable with the structure (or > lack of) of the plugin. > > For example - plugin_comment I would prefer to see as in a directory - so > that distribution and installation would be simpler (as well as coding). > The naming convention (while good, quick for proof of concept) I would like > to see more thought on. I would prefer to see an application folder > "plugins" with all the requisite folders - models, controllers, etc. - where > you could install "comments" and "rankings" etc. (for example). It might > be interesting to have site-wide (e.g. accross applications) plugins, where > if your plugin is not found in the app area, then it is looked for in the > global area (so, perhaps there would be a web2py/applications folder, and a > parallel web2py/components folder). > > From a programming perspective, I would prefer to see this managed as > classes, so for example I would have a new comments class which is a Plugin > (or Component - I actually like that term better), but I haven't thought > through this completely. This would probably change all sorts of things, > perhaps even encapsulating the models and controllers (but that may be a bit > much). > > In any case, this is a nice start, and I would like to think about it some > more. Perhaps we should have an alpha version, and collect experiences for > a while. > > - Yarko > > On Thu, Oct 1, 2009 at 10:53 AM, Pynthon <[email protected]> wrote: > > I think the proposed system is minimally disruptive, programmers do > > not need to know anything about AJAX/JSON > > > That sounds very good. I watched the video and it looks very good! > > > 2009/10/1 mdipierro <[email protected]> > > >> I just mean that if we want plugin components to return JSON instead > >> of using the proposed mechanism, than people programming plugins would > >> not be able to return a dict() and have it rendered by a view as they > >> are used to, we would have to create a new programming paradigm and > >> new functions (API) to deal with it. > > >> I think the proposed system is minimally disruptive, programmers do > >> not need to know anything about AJAX/JSON and I should be able to > >> handle it with a single new chapter in the book. ;-) > > >> Massimo > > >> On Oct 1, 10:03 am, Pynthon Pynthon <[email protected]> wrote: > >> > Maybe I did not understand the word API but that means you need to > >> rebuild > >> > everything? Or do you mean a new json API? > > >> > Sorry :$. > > >> > 2009/10/1 mdipierro <[email protected]> > > >> > > One rarely needs to return metadata (js/flash) with response and with > >> > > the proposed mechanism one would not need any special API to create a > >> > > plugin. If using json the response would have to be encoded in json > >> > > and this would require new api. > > >> > > On Oct 1, 9:25 am, AndrewLoot <[email protected]> wrote: > >> > > > Whats the benefit of using headers for inter-component communication > >> > > > why not pass a json object in with the response? > > > -- > > Please visit my blog pynthon.naar.info --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
