We're still shoveling a lot of terminology at each other while mostly agreeing on things esp with regard to plugins. If left to my own devices, I'd put in something into __init__.py in the application folder and/or name the folder itself plugin_[pluginname] so it's clear both visually and programmatically who/what's a plugin and who/what isn't. I don't have a problem with applications being plugins (or was it rather the other way round :) ). Local versions of plugins (=per application) are IMHO a mess no matter how you do it.
As for billf's comments, I mostly agree, but I don't see this being done without a) going v2.0 and b) having a goal, yes, clean is cool, but don't rewrite code just because you're smarter after you've written it. Sure enough, my engineering sense tells me that rewrites that make stuff cleaner are good, but from experience, unless you have a reason to rewrite with regard to the future, that time is better spent on more pressing/common issues (I sincerely hope people understand what I'm saying here, it's not about (non-)messy code, but rather how to maximize development pace for a given 'amount' of effort). On Jan 21, 10:47 pm, mdipierro <[email protected]> wrote: > no. I can use help in "inventing" them. > > Massimo > > On Jan 21, 3:45 pm, billf <[email protected]> wrote:> What is > aPLUGINfile and do any exist already? > > > On Jan 21, 6:05 pm, mdipierro <[email protected]> wrote: > > > > > * I think that the very fact that you can take parts of T2 and > > > > incorporate them in the core proves that apluginis not necessarily > > > > an app (in the recognised sense of the word). If Auth is replaceable > > > > by aplugin, it is (or may as well be) apluginitself. The key > > > > element is how thatpluginis integrated. In the case of Auth, I > > > > seems it must be via Crud (I could be wrong) but Crud enforces a URL > > > > format which surely can't be mandatory to handle authorisation. > > > > Stuff is moved into core only if can be done in a module without > > > services, static files and without mandating conventions on how to > > > expose them. Nevertheless Auth and Crud do provide a "simple" and > > > "naive" way to expose themselves until the developer figures out how > > > that can be customized (I will document it eventually). > > > > > * you say apluginis an app and "does not deserve a special folder > > > > butpluginapps need to identify themselves. I think aPLUGINfile in > > > > the app folder should do the task." But in the previous sentence you > > > > say aplugin" can have modules, models, controllers, views, static > > > > files, services." That is contradictory isn't it. > > > > No. thepluginis an app (which already contains modules, static, > > > etc.) > > > thePLUGINfile is needed to describe via some metadata or text how > > > this app exposes services that other apps can use. Thus making it a > > > spacial app, thepluginthat is. > > > > > * Neither of the above apply to Auth which doesn't have a lot of other > > > > files but isnt in an "app folder" either. > > > > The way I am implmenting it does not need to be an app. But class > > > CasAuth(Auth):pass needs to be an app because exposes CAS provider > > > services. > > > > > * when you say "in the app folder" do you mean "applications" folder > > > > or the same folder as the app? (I'm assuming the latter) So every > > > > app that requires Auth must have it's own copy of theplugin? I'm not > > > > sure whether that is good/bad. > > > > Every application that requires Auth will just need web2py and do from > > > gluon.utils import Auth! > > > If an app needs apluginthat extends Auth by providing for example > > > CAS would need theplugin(as they need CAS now). > > > > It has. It just has not been explained properly perhaps. It is also > > > true that different people expect different things from a "plugin". > > > For me a "plugin" is defined as an "app" that provides modules, > > > services, views and static files, that can be used by other apps. This > > > means I do not want specifications to be too strict. If you are > > > expecting more from it perhaps you should explain what you would like. > > > > Massimo > > > > > I'm sorry, it just seems the thing hasn't been thought thru. > > > > > On Jan 21, 4:09 pm, mdipierro <[email protected]> wrote:> Hi Bill, > > > > > > I will try to answer some of the questions you raised in the thread. > > > > > > We had an IRC meeting last week and we agreed that T2 was becoming > > > > > common and people started to rely on it. At the same time maintaining > > > > > web2py+T2+T3 as separate entities was becoming a nightmare. We agreed > > > > > that it was possible to incorporate some parts of T2 (those that we > > > > > consider good practice and those that only require python modules) > > > > > into web2py. > > > > > This includes: > > > > > - Authentication > > > > > - Role Based Authorization > > > > > - Smarter Crud than SQLFORM provides (integration with authentication, > > > > > more restful paths) > > > > > > The current T2 would become an example on how to extend this core, in > > > > > the same fashion as you suggest. > > > > > > T3 will stay an anonymous app that based only on web2py and perhaps, > > > > > once polished, it could be distributed with web2py in the future. > > > > > > About the "concept" ofplugin. I agree with almost everything you say > > > > > but let me insist: APLUGINIS AN APPLICATION. Just a special type of > > > > > app. It can have modules, models, controllers, views, static files, > > > > > services. It does not deserve a special folder butpluginapps need to > > > > > identify themselves. I think aPLUGINfile in the app folder should do > > > > > the task. > > > > > > We do need to write API specs on how to write plugins. > > > > > > For example. By having Auth provided now by web2py code, aplugin > > > > > could be > > > > > > class CasAuth(Auth): ... > > > > > > which exposes the same APis as Auth but uses CAS. Thepluginwould > > > > > also include a CAS provider app. > > > > > > Massimo > > > > > > On Jan 21, 9:19 am, billf <[email protected]> wrote: > > > > > > > RE plugins, I think the other area that could be addressed is how > > > > > > web2py allows certain types ofpluginto operate. > > > > > > > For example, it would be nice if web2py says "I provide for the > > > > > > following types of authorisation at point x, y, and z where I will > > > > > > call a function (either called a, b and c or stored in attributes > > > > > > d, e > > > > > > and f)", i.e. the api that a "standard" authorisationpluginmust > > > > > > meet. That way a) anyone writing their own know what they have to > > > > > > provide and b) it documents what web2py must support for backwards- > > > > > > compatibility. > > > > > > > There are probably some internal areas that might benefit from a > > > > > > similar api document, e.g. the "api" exposed to a view, although I > > > > > > can't quite envisage it at present. > > > > > > > On Jan 21, 2:47 pm, billf <[email protected]> wrote: > > > > > > > > For now, I don't know if there is a difference between module and > > > > > > >pluginbut let's assume there is to keep it discreet. > > > > > > > > * apluginfolder > > > > > > > > * eachpluginis a) a file or b) a folder - latter is more flexible > > > > > > > if > > > > > > > more than file required > > > > > > > > * an admin UI can display all plugins from thepluginfolder > > > > > > > > * a means of stating dependency upon other plugins and conflict > > > > > > > with > > > > > > > other plugins so that the admin UI can automatically > > > > > > > check/include/ > > > > > > > warn - is this by lines within the main(?)pluginfile or a separate > > > > > > > config/manifest/descriptor file > > > > > > > > * a means of describing theplugin- in text including syntax (same > > > > > > > points as above lines or file) > > > > > > > > * I don't know the best way to actually import/include into app/ > > > > > > > project - any ideas? > > > > > > > > Bill > > > > > > > > On Jan 21, 2:08 pm, Timothy Farrell <[email protected]> wrote: > > > > > > > > > So the big question is...what would apluginsystem look like? > > > > > > > > What > > > > > > > > would you want it to control? > > > > > > > > > Currently the T2 functionality is a set of Python methods that > > > > > > > > you can > > > > > > > > expose and add to your app. I agree that it looks cludgy, but > > > > > > > > how can > > > > > > > > it be made better? > > > > > > > > > I want to keep things narrow in this discussion. So let's have > > > > > > > > an > > > > > > > > example: Authentication. Let's say I have an app and I want to > > > > > > > > add > > > > > > > > authentication to it (aside from Basic HTTP auth). How would > > > > > > > > aplugin > > > > > > > > add this functionality to my app? > > > > > > > > > -tim > > > > > > > > > billf wrote: > > > > > > > > > I've been away a while so I am trying to catch up with all > > > > > > > > > the new > > > > > > > > > stuff. I've downloaded the version in trunk and I'm trying > > > > > > > > > to get my > > > > > > > > > head around it all. My first (admittedly very early) > > > > > > > > > impressions are: > > > > > > > > > > 1) The functionality is nice but, personally, I don't see > > > > > > > > > utils.py > > > > > > > > > stuff as core web2py. > > > > > > > > > > 2) I would prefer to see a simple, well-defined, rock-solid > > > > > > > > > core and > > > > > > > > > everything else as aplugin. I accept that where you draw the > > > > > > > > > line is > > > > > > > > > totally subjective. For example , I have no problem with a > > > > > > > > > mandatory > > > > > > > > > 'id' and would like to see an optional > > > > > > > > > 'last_modification_timestamp' > > > > > > > > > included in the core. Others want neither. I have a problem > > > > > > > > > with > > > > > > > > > Mail, Auth and Crud in the core. I'm sure others see no > > > > > > > > > problem. > > > > > > > > > > 3) Someone devise a goodpluginsystem pleeeeeease. Or a > > > > > > > > > requirements > > > > > > > > > spec for one? I know; "do it yourself" :-) > > > > > > > > > > 4) There is a bug in utils.py: lines 821, 833 and 849 should > > > > > > > > > all refer > > > > > > > > > to self.settings. not self.setting. > > > > > > > > > > [BTW is it possible to override the redirect at the end of > > > > > > > > > create(), > > > > > > > > > update() and delete()? I couldn't.] > > > > > > > > > > 5) The url > > > > > > > > > format:http://..../[app]/default/database/create/[app]_event > > > > > > > > > ...has got to be the least elegant way of saying "I want a > > > > > > > > > form to add > > > > > > > > > a record to table [app]_event" you could think of. Shouldn't > > > > > > > > > the goal > > > > > > > > > be:http://..../[app]/default/[app]_event ? > > > > > > > > > > 6) Crud just seems a way to minimise the need to write > > > > > > > > > function stubs > > > > > > > > > (by enforcing action/table/id in the url) and enforcing a > > > > > > > > > call to Auth > > > > > > > > > if present. It's just really a pattern for a do-everything > > > > > > > > > function. > > > > > > > > > > 7) I think web2py is struggling to define itself. Is it: > > > > > > > > > > - a powerful general-purpose framework (that could do with a > > > > > > > > > little > > > > > > > > > attention to its foundations)? > > > > > > > > > > - a cms with a long way to go? > > > > > > > > > > - some sort of app-builder app for plugins/modules with > > > > > > > > > noplugin/ > > > > > > > > > module api/infrastructure? > > > > > > > > > > I don't think it will succeed if it tries to be more than one > > > > > > > > > of the > > > > > > > > > above. But maybe I'm just not aspirational enough. > > > > > > > > > > Obviously, the above is mostly personal hot air but then > > > > > > > > > that's what a > > > > > > > > > forum's for :-) > > > > > > > > > > Bill > > > > > > > > > > On Jan 21, 9:46 am, mdipierro <[email protected]> wrote: > > > > > > > > > >> yes but only so that you can test them and provide feedback. > > > > > > > > >> I hope > > > ... > > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" 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 -~----------~----~----~----~------~----~------~--~---
