future of T2 is *almost* here

[mdipierro]

I have a preliminary version of inclusion if T2 functionality into
web2py core. I am not yet promising backward compatibility here. The
module name many change. For now it is in trunk as gluon/utils.py

Here is how you use it (assuming [app] is you application name).

1) put this in your model

from gluon.utils import *
auth=Auth(globals(),db)
auth.define_tables()
crud=Crud(globals(),db)

2) put this in your "default" controller

def user(): return dict(form=auth())
def database(): return dict(form=crud())
def download(): return response.download()

def index():
response.flash=T('Welcome to web2py')
return dict(message=T('Hello World'))

Now visit:
http://..../[app]/default/user/register
http://..../[app]/default/user/login
http://..../[app]/default/user/profile
http://..../[app]/default/user/change_password
http://..../[app]/default/user/groups
http://..../[app]/default/user/logout
http://..../[app]/default/user/retrieve_password

http://..../[app]/default/database/tables
http://..../[app]/default/database/select/[app]_event
http://..../[app]/default/database/create/[app]_event
http://..../[app]/default/database/read/[app]_event/1
http://..../[app]/default/database/update/[app]_event/1
http://..../[app]/default/database/delete/[app]_event/1

now add to the model

mail=Mail()
mail.settings.server='smtp.whetever.com'
mail.settings.sender='y...@whatever.com'
mail.settings.longin='username:password'
auth.settings.mail=mail

so that registration requires email verification

then add

auth.settings.captcha=RECAPTCHA
(request,public_key='RECAPTCHA_PUBLIC_KEY',private_key='RECAPTCHA_PRIVATE_KEY')

so that registration will use recaptcha

then add

crud.auth=auth

so that crud will enforce role based access control....

now you lost the permission to access http://.../database/....

now give yourself back permission *only* to select record in table
[app]_user

group_id=auth.add_group(role='Manager')
auth.add_membership(group_id,auth.user.id)
auth.add_permission(group_id,'select','[app]_user')

or to delete users

auth.add_permission(group_id,'delete','[app]_user')

get the idea?.... I think I have been following (or tried to) the
advice of some of the members here like Yarko, Ceej, Bill, Fran, and
others.

There is a lot more stuff in there (like decorators that enforce
permissions) that needs polishing and documenting.

Volunteers to help?

Massimo

[David Marko]

These things look very nice.
Does it mean that described changes are available in svn trunk
version?

David

On 21 Led, 00:36, mdipierro <mdipie...@cs.depaul.edu> wrote:
> I have a preliminary version of inclusion if T2 functionality into
> web2py core. I am not yet promising backward compatibility here. The
> module name many change. For now it is in trunk as gluon/utils.py
>
> Here is how you use it (assuming [app] is you application name).
>
> 1) put this in your model
>
> from gluon.utils import *
> auth=Auth(globals(),db)
> auth.define_tables()
> crud=Crud(globals(),db)
>
> 2) put this in your "default" controller
>
> def user(): return dict(form=auth())
> def database(): return dict(form=crud())
> def download(): return response.download()
>
> def index():
>     response.flash=T('Welcome to web2py')
>     return dict(message=T('Hello World'))
>

> Now visit:http://..../[app]/default/user/registerhttp://..../[app]/default/user/loginhttp://..../[app]/default/user/profilehttp://..../[app]/default/user/change_passwordhttp://..../[app]/default/user/groupshttp://..../[app]/default/user/logouthttp://..../[app]/default/user/retrieve_password
>
> http://..../[app]/default/database/tableshttp://..../[app]/default/database/select/[app]_eventhttp://..../[app]/default/database/create/[app]_eventhttp://..../[app]/default/database/read/[app]_event/1http://..../[app]/default/database/update/[app]_event/1http://..../[app]/default/database/delete/[app]_event/1

>
> now add to the model
>
> mail=Mail()
> mail.settings.server='smtp.whetever.com'

> mail.settings.sender='...@whatever.com'

> mail.settings.longin='username:password'
> auth.settings.mail=mail
>
> so that registration requires email verification
>
> then add
>
> auth.settings.captcha=RECAPTCHA

> (request,public_key='RECAPTCHA_PUBLIC_KEY',private_key='RECAPTCHA_PRIVATE_K EY')

>
> so that registration will use recaptcha
>
> then add
>
> crud.auth=auth
>
> so that crud will enforce role based access control....
>

> now you lost the permission to accesshttp://.../database/....

[mdipierro]

yes but only so that you can test them and provide feedback. I hope to
finalize the APIs and documentations within the week.

also I would like to change the name of the file from utils.py to
something more catchy. Any suggestion?

Massimo

[Jonathan Benn]

On Jan 21, 12:46 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:

> also I would like to change the name of the file from utils.py to
> something more catchy. Any suggestion?

high_level_enhancements.py ?

[Markus Gritsch]

Way to unwieldy, IMO.

The gluon folder already contains a 'fileutils.py'. How about
* 't2utils.py', or
* 'authutils.py', or just 'auth.py' which contains the Auth() class
and 'crudutils.py', or just 'crud.py' which contains the Crud() class.

Markus

[Timothy Farrell]

I might actually start using T2 functionality now. This is good stuff!

--
Timothy Farrell <tfar...@swgen.com>
Computer Guy
Statewide General Insurance Agency (www.swgen.com)

[billf]

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 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 no plugin/
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

[Timothy Farrell]

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]

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

> Timothy Farrell <tfarr...@swgen.com>

[billf]

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.

[mdipierro]

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

[Robin B]

To do 'last_modification_timestamp' add the more general cases:
oncreate= and onupdate= callbacks to db.Field.

A plugin system needs versioning and dependencies, and instead of
creating a one off web2py plugin spec, it is better to reuse the
standard egg spec. Eggs can be installed as directories or zip files
(works on GAE too). Ian Bicking's virtualenv, which uses eggs, is
used for Pylon's plugin system. The reason web2py does not use
virtualenv is because virtualenv modifies the sys.path. The solution
for web2py plugins is to use eggs and import them without modifying
the sys.path (use __import__ trick).

Robin

> ...
>
> read more »

[billf]

Massimo

I accept that whatever I think, the majority rules and if you don't
contribute to the discussion you can't complain about the decision -
and I'm not - I think it's all v.healthy.

re T2 and plugins:

* 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.

* 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.

* Neither of the above apply to Auth which doesn't have a lot of other
files but isnt in an "app folder" either.

* 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.

I'm sorry, it just seems the thing hasn't been thought thru.

> ...
>
> read more »

[mdipierro]

> * 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

[vince]

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

> ...
>
> read more »

[mdipierro]

Yes that is the idea. That is what plugin_t2 and plugin_checkout do
now.
Admin can already handle them since a plugin is also an app. What is
missing is a protocol for describing the functionality of the plugin.

Massimo

Massimo

> ...
>
> read more »

[Robin B]

> 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

> ...
>
> read more »

[mdipierro]

I will take a look. Thank you.

> ...
>
> read more »

[billf]

What is a PLUGIN file and do any exist already?

> ...
>
> read more »

[mdipierro]

no. I can use help in "inventing" them.

Massimo

> ...
>
> read more »

[billf]

I think this thread (the plugin bit) is getting a little like 'war and
peace' and as Tim said earlier it would be nice to focus on
specifics. I thought some sleep might help me take a step back so
this a.m. I looked at my original post and realise that my original
point was that I don't think Auth and Crud should be core. The
ensuing discussion re plugins has just convinced me that I am right
(not that difficult a task usually).

IMHO there are (at least) 3 types of added functionality:
1) fundemental/core: e.g. database access is performed via a DAL,
tables support select, insert, etc

2) optional, interaction with core: e.g. you can use an Oracle
database if you want, you must have permission before you can delete a
record

3) optional, interaction with application: e.g. you can add stuff to a
shopping cart, you can wrap common functionality in a higher-level
object

In my mind, both 2) and 3) should be implemented as plugins.

In the case of 2), web2py should define an API (hooks, whatever you
want to call it), the appropriate plugins loaded and the core calls
the functions of the appropriate plugin. Sure, sql.py works with a
million "if db=='oracle'" statements but would you teach someone to
write code like that?

Similarly, the core should expose hooks to check authoristation. This
is not how Auth/Crud are being integrated into the core now.

Now whether the mythical plugins I have just described are provided
with the web2py distribution or some third-party is immaterial. I
believe it is the most useful structure (clear interface, smaller
chunks of code, simpler code, more easily tested, more easily
replaceable, etc). Ok, it might be asking a lot to re-write sql.py
but before adding T2 stuff to the core I think there is an opportunity
to do it better this time round.

Whether type 2) and type 3) should share the same management structure
- I don't know - why not?

Bill

> ...
>
> read more »

[achipa]

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 <mdipie...@cs.depaul.edu> wrote:
> no. I can use help in "inventing" them.
>
> Massimo
>

> On Jan 21, 3:45 pm, billf <billferr...@blueyonder.co.uk> wrote:> What is aPLUGINfile and do any exist already?

>
> > On Jan 21, 6:05 pm, mdipierro <mdipie...@cs.depaul.edu> 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).

> > > > > 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 <billferr...@blueyonder.co.uk> 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 <billferr...@blueyonder.co.uk> 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 <tfarr...@swgen.com> 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

[Peter]

Hi Massimo,

Some feedback on utils.py from an "occasional" web2py developer.

I found lots to like in Auth compared to the current t2.py, ie:
- increased customization in the Auth API, ie settings.mailer (eg, I
have use a html mail function)
- support for username instead of email as primary user id

In my current app I have copied & pasted (brrrr...) several Auth
functions because it looked unwise to subclass t2 -- there being a
single t2 instance. But in this new setup I should be able to subclass
Auth and redefine only one or two specific methods. Right?

Re Crud, you hint at onvalidation support in the new crud functions --
that would be *really* welcome. In general, I would like to be able to
pass more SQLFORM params to crud functions (eg, fields?) -- more
customization and delegation options help to move T2 crud from a "90%"
solution closer to 98 or 99...

Finally, I don't want to go all java on you, but wouldn't more
explicit APIs help to put some distance between interface and
implementation -- and thus easier to reimplement or modify parts that
need this? My impression is that the current APIs are primarily
function signatures, and that underlying dependencies, side effects
and interfaces to data structures are sometimes left as an exercise
for the reader. ;-)

Web2py is evolving so fast that between the Book, epydocs, Alterego
and the current "complete" API on the website, I find am looking at
web2py source (and running dir() in a shell) much more often than I
probably should. I do realize that the docs have to catch up with
development. Isn't it time to consider a single new (collaborative?)
reference for the evolving web2py APIs? Not just the technical
interface definitions (a la epydocs), but the semantics as well. I'd
be happy to contribute where I can -- within the limitations that come
with my "occasional" status.

Hope this helps,
Cheers,
-Peter

[mdipierro]

Peter I agree with you.

Sorry I have been slow digesting this thread but it is very
interesting.
The pycon registration will keep me busy for the next couple of days.

Massimo

[billf]

Achipa

I agree with your logic about rewrite 100% but that is why I was
suggesting applying any new approach to Auth as that is not yet set in
concrete.

I think your comments re maximizing development pace for a give amount
of effort are really interesting. Tho' it does remind me of the story
about the guy who jumped from a skyscraper and as he went past the
13th floor said "so far so good".

Bill

> ...
>
> read more »

[Wes James]

On Tue, Jan 20, 2009 at 4:36 PM, mdipierro <mdip...@cs.depaul.edu> wrote:
>
> I have a preliminary version of inclusion if T2 functionality into
> web2py core. I am not yet promising backward compatibility here. The
> module name many change. For now it is in trunk as gluon/utils.py
>

<snip>

>
> auth.settings.captcha=RECAPTCHA
> (request,public_key='RECAPTCHA_PUBLIC_KEY',private_key='RECAPTCHA_PRIVATE_KEY')

I put the above in and on the login page I get:

Invalid public key. Make sure you copy and pasted it correctly.

I also have RECAPTCHA(....)

that was an email line break right?

-wj

[Wes James]

On Tue, Jan 20, 2009 at 4:36 PM, mdipierro <mdip...@cs.depaul.edu> wrote:
>
> I have a preliminary version of inclusion if T2 functionality into
> web2py core. I am not yet promising backward compatibility here. The
> module name many change. For now it is in trunk as gluon/utils.py
>

Where does this go?

>
> group_id=auth.add_group(role='Manager')
> auth.add_membership(group_id,auth.user.id)
> auth.add_permission(group_id,'select','[app]_user')

I get:

auth.add_membership(group_id,auth.user.id)
AttributeError: 'NoneType' object has no attribute 'id'

so i've put it in the wrong place (db.py right now - should it go in a
controller page?)

Seems to work now that I put it in:

controllers/default.py

def index():
group_id=auth.add_group(role='Manager')
auth.add_membership(group_id,auth.user.id)
auth.add_permission(group_id,'select','tnew_user')

response.flash=T('Welcome to web2py')
return dict(message=T('Hello World'))

-wj

[mdipierro]

Bill,

when gluon.utils is completed this is exactly what we need.

On Jan 21, 9:19 am, billf <billferr...@blueyonder.co.uk> wrote:

[mdipierro]

Could you provide an example of how to import and egg
programmatically?

Massimo

> ...
>
> read more »

[Robin B]

> Could you provide an example of how to import and egg
> programmatically?

Well that is the catch. Eggs rely on setuptools to do install,
versioning, and dependencies. It will be a little tricky to make site-
packages for each application, since setup tools was not created to
have more than one site-packages dir, thus virtualenv, but virtualenv
also monkeys with the sys.path.

So here is one idea:

Use easy_install to install dependencies to python's site-packages dir
or better yet web2py/site-packages, then have another web2py script
that reads an applications egg spec and copies the versions of all
required eggs from site-packages to applications/foo/plugins/ .
When run, the script needs to be fully automated to remove/add eggs
with the latest required versions from root site-packages, this way
applications contain the eggs/versions they need and only the eggs/
versions they need.

This way you get the benefits of setuptools/eggs and applications can
be distributed as stand alone.

The next part is how to actually import them:

This is where setuptools goes wrong:

from pkg_resources import require
require("SomePackage", "OtherPackage", "MyPackage")
"which will put the latest installed version of the specified packages
on sys.path for you."


We do not want to modify the sys.path so we make our own require, it
could be mixed into the exec_env:

Internally require could use mod_import from here:
http://groups.google.com/group/web2py/browse_thread/thread/f9e117f081cfab24/e2f66268d0fb0471?hl=en&lnk=gst&q=__import__#e2f66268d0fb0471

def require(app):
def require(name_and_version):
plugin = rewrite_plugin_str(name_and_version)
return mod_import('applications.%s.plugins.%s'%(app,plugin))
return require
require = require(request.application)
...

simplejson = require('simplejson<2.0')
or
simplejson = require('simplejson')



So each application would need an egg spec that lists its plugins
(eggs) and any specific versions. Dependencies are resolved and all
needed eggs are copied to the application's plugins dir.

Say you want to install 'ThatPlugin':

easy_install ThatPlugin
add ThatPlugin as a dependency in myapps's egg spec
python web2py/scripts/install_plugins myapp #reads specs, copies eggs

The install_plugins script could make full use of setuptools locally
to parse the specs, we2py.plugins.require will need to be compatible
with setuptools but not depend on setuptools because setuptools will
not be available on the production platform (eg GAE).

> ...
>
> read more »

[Yannick]

Thanks for the note...
I try this example and I have the following error message:
"
Traceback (most recent call last):
File "/opt/web2py/gluon/restricted.py", line 62, in restricted
exec ccode in environment
File "/opt/web2py/applications/myapp/models/db.py", line 13, in
<module>
from gluon.utils import *
ImportError: No module named utils
"

Did you change the module Utils to something else ? I'm using the
latest version Web2Py Version 1.55.2

Thanks.

On Jan 20, 6:36 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> I have a preliminary version of inclusion if T2 functionality into
> web2py core. I am not yet promising backward compatibility here. The
> module name many change. For now it is in trunk as gluon/utils.py
>
> Here is how you use it (assuming [app] is you application name).
>
> 1) put this in your model
>
> from gluon.utils import *
> auth=Auth(globals(),db)
> auth.define_tables()
> crud=Crud(globals(),db)
>
> 2) put this in your "default" controller
>
> def user(): return dict(form=auth())
> def database(): return dict(form=crud())
> def download(): return response.download()
>
> def index():
>     response.flash=T('Welcome to web2py')
>     return dict(message=T('Hello World'))
>
> Now visit:http://..../[app]/default/user/registerhttp://..../[app]/default/user/loginhttp://..../[app]/default/user/profilehttp://..../[app]/default/user/change_passwordhttp://..../[app]/default/user/groupshttp://..../[app]/default/user/logouthttp://..../[app]/default/user/retrieve_password
>
> http://..../[app]/default/database/tableshttp://..../[app]/default/database/select/[app]_eventhttp://..../[app]/default/database/create/[app]_eventhttp://..../[app]/default/database/read/[app]_event/1http://..../[app]/default/database/update/[app]_event/1http://..../[app]/default/database/delete/[app]_event/1
>
> now add to the model
>
> mail=Mail()
> mail.settings.server='smtp.whetever.com'

> mail.settings.sender='...@whatever.com'
> mail.settings.longin='username:password'
> auth.settings.mail=mail
>
> so that registration requires email verification
>
> then add
>
> auth.settings.captcha=RECAPTCHA

> (request,public_key='RECAPTCHA_PUBLIC_KEY',private_key='RECAPTCHA_PRIVATE_KEY')

>
> so that registration will use recaptcha
>

[Yannick]

[mdipierro]

sorry it was renamed

gluon.tools

[Yannick]

Thanks for the note...
I still have the same type of error message here it is:

"
Traceback (most recent call last):
File "/opt/web2py/gluon/restricted.py", line 62, in restricted
exec ccode in environment
File "/opt/web2py/applications/myapp/models/db.py", line 13, in
<module>

from gluon.tools import *
ImportError: No module named tools
"

And even when I go in the "...\web2py\gluon" directory I don't find
any "tools.py" ?
Hmmm do you think I forgot something ? Do I need a plug-in ? I'm
currently using the latest version of Web2py.

Thanks for your help

[mdipierro]

sorry. trunk only for now. There will be a new version in 1-2 weeks.

[Yannick]

Oh ok i see... I'll wait :)
Thanks