I will take a look. Thank you.

On Jan 21, 1:33 pm, Robin B <[email protected]> wrote:
> >  What is missing is a protocol for describing the functionality
> >  of the plugin.
>
> Paste uses an .ini file to explicitly describe what implements what:
>
> [app:myapp]
> paste.app_factory = myapp.modulename:app_factory
>
> http://pythonpaste.org/deploy/#config-format
>
> Robin
>
> > On Jan 21, 12:46 pm, vince <[email protected]> wrote:
>
> > > would it be better if plugin can share between application so we can
> > > only need to maintain one copy? also if the admin page can simplify
> > > the plugin installation that would be great.
>
> > > -vince
>
> > >  On Jan 22, 2:05 am, 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 a plugin is not necessarily
> > > > > an app (in the recognised sense of the word). If Auth is replaceable
> > > > > by a plugin, it is (or may as well be) a plugin itself.  The key
> > > > > element is how that plugin is 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 a plugin is an app and "does not deserve a special folder
> > > > > but plugin apps need to identify themselves. I think a PLUGIN file in
> > > > > the app folder should do the task."  But in the previous sentence you
> > > > > say a plugin " can have modules, models, controllers, views, static
> > > > > files, services."  That is contradictory isn't it.
>
> > > > No. the plugin is an app (which already contains modules, static,
> > > > etc.)
> > > > the PLUGIN file 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, the plugin that 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 the plugin? 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 a plugin that extends Auth by providing for example
> > > > CAS would need the plugin (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" of plugin. I agree with almost everything you 
> > > > > > say
> > > > > > but let me insist: A PLUGIN IS 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 but plugin apps need 
> > > > > > to
> > > > > > identify themselves. I think a PLUGIN file 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, a plugin
> > > > > > could be
>
> > > > > > class CasAuth(Auth): ...
>
> > > > > > which exposes the same APis as Auth but uses CAS. The plugin would
> > > > > > 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 of plugin to 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" authorisation plugin must
> > > > > > > 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
> > > > > > > > plugin but let's assume there is to keep it discreet.
>
> > > > > > > > * a plugin folder
>
> > > > > > > > * each plugin is a) a file or b) a folder - latter is more 
> > > > > > > > flexible if
> > > > > > > > more than file required
>
> > > > > > > > * an admin UI can display all plugins from the plugin folder
>
> > > > > > > > * 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(?) plugin file or a 
> > > > > > > > separate
> > > > > > > > config/manifest/descriptor file
>
> > > > > > > > * a means of describing the plugin - 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 a plugin system 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 
> > > > > > > > > a plugin
> > > > > > > > > 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 a plugin.  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 good plugin system 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
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to