Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Enterprise Python Beans (TM)

23 views
Skip to first unread message

Massimo Di Pierro

unread,
May 18, 2008, 5:22:37 PM5/18/08
to web...@googlegroups.com
I have been thinking of your insistent request for reusability. There
are some thoughts on the matter....

1) different apps can share one database db=SQLDB(....)

2) different apps can now share sessions using session.connect
(request,response,db=...,masterapp='appname')

3) we still need a convention for making code reusable (only a
convention since modules already provide the technology to do it).

About 3). The convention needs to encapsulate in a module a
functional unit that contains a db connection, a representation of
its own models, some business logic and perhaps expose its own
helpers. Let's call this object Enterprise Python Bean (EPB). Here
would be an example of a Bean defined in applications/epb/modules/
ShoutingBean.py

from gluon.sql import *
from gluon.sqlhtml import *
from gluon.validators import *

class ShoutingBean:
"""
This is s web2py Enterprise Python Bean example!
"""
def __init__(self):
self.db=SQLDB("sqlite://bean_shootout.db")
self.db.define_table('shout',SQLField('message'))
self.db.shout.message.requires=IS_NOT_IN_DB
(self.db,'shout.message')
def accepts(self,request_vars):
self.form=SQLFORM(self.db.shout)
return self.form.accepts(request_vars)
def get_form(self):
return self.form
def get_rows(self):
return self.db().select(self.db.shout.ALL)
def act_on(self,request,response):
return dict(rows=self.get_rows()) if self.accepts
(request.vars) else dict(form=self.get_form())

Now you can write a single controller (no model) that uses it, for
example in applications/epb/controllers/default.py

from applications.epb.modules.ShoutingBean import ShoutingBean
def index(): return ShoutingBean().act_on(request,response)

You can try it. It works! It creates the db, creates the tables,
makes an input form with validation, upon submissions - if validation
passes - it lists all messages.

The Bean is easy to reuse.

I also have a version of web2py that allows serialization of the
SQLDB objects (including its tables) and result of a select(). This
means that beans could also be serialized (as in Enterprise Java
Beans), stored in sessions, stored in database, transmitted via http/
xmlrpc, etc. (now you know what the previous post was about!).

I think of a EPB as a black-box mini sub-app that can be shared by
multiple apps and carries its own state and its own documentation
(__doc__).

Because of the EJB analogies this has great marketing potential.

The question is how strict should the specifications be? Any EJB
expert here? I am not.

Can you think of applications? Possibly weird but useful applications.

Is this the right direction? Certainly not for everybody but would
this be a good idea for those of you working on large applications?

Would you like to help in drafting specs?

Please share your thoughts.

Massimo

ygao

unread,
May 18, 2008, 8:49:02 PM5/18/08
to web...@googlegroups.com
I dont like this red code line.
 
I 'm very happy to see this. you begin to make web2py changes.
that's a good beginning.but I don't like this idea.yeah,it is better,it is not the best web2py way.
you break the web2py app way.and thanks you give me a another idea.
 
BTW:  limodou is creating his own python web framework.

mdipierro

unread,
May 18, 2008, 9:24:26 PM5/18/08
to web2py Web Framework
> I 'm very happy to see this. you begin to make web2py changes.
> that's a good beginning.but I don't like this idea.yeah,it is better,it is
> not the best web2py way.
> you break the web2py app way.and thanks you give me a another idea.

I am not proposing any change to web2py. I am proposing writing
specifications for building reusable components.
I do not want to change web2py. Backward compatibility will not be
broken.

> BTW: limodou is creating his own python web framework.

Great. He has given a big contribution to web2py. I hope he will
continue to do so.

Massimo

limodou

unread,
May 18, 2008, 9:45:43 PM5/18/08
to web...@googlegroups.com
I'm also thinking what stuffs should we share. Because some frameworks which I used don't have this problem. For django, all the apps will consist one sigle project, so you can directly import views and models. But in web2py, apps, controllers and models are separate, and they are event not normally python module, so you can not directly import them, this machenism is very different from other frameworks. So we can not just reuse them via importing module as other frameworks. Then, what stuffs should we share? I've not thing well so much:

1. Database definition, and for database connection I haven't think well.
2. Templates or views. We can create reusable templates and combine them in one views, and these templates can be in differnet apps.
3. Controller functions. In django, there are generic views which you can use them, so we can also write something like these and reuse them.

But I should admit, I think reusability and independence has some conflict. So I don't know if they can exists together.

And I've created a testing framework, named kuaiboo, for personal usage now, you can found at:

http://mymisc.googlecode.com/svn/trunk/kuaiboo

I borrow something from web2py, django, werkzeug, etc. And when you run the view function(there is no controller in kuaiboo, just like django), I'll bind some environment variables to that function, here is a very simple test:

>>> def f():
...     print request
...    
>>> f.func_globals['request'] = 'hello'
>>> f()
hello

So you can see, we can bind some variable to func.func_globals and direct use them in function. This thing just like run in exec, and we can also put some global functions into __builtin__, so that, we can use them directly in module level. But with this way you should prepare and env and binds them into function.func_globals or __builtin__, and for request, response are not easy deal with. Because you can write some moule level proceess in web2py controller, so you can not set request, response in func_globals only in __builtin__, but it'll be global and not threadsafe. So there are other ways I think:

1. Wrap module level process into decorator, for example:

def process(func):
    response process
    request process
    return func

@proceess
def index()

2. define some special functions,  for example __before__, and when you execute a controller function, execute it first, in dispatcher, like:

req = Request(environ)
res = Response()
before = getattr(controller, '__before__', None)
if before:
    run_controll(before, req, res, env)
handler = getattr(controller, function)
response = run_controll(handler, req, res)

But all these things will break the compatibility.

For EPB, I've not thought well also. The important thing is what stuff should we share. If you need a full-functional stuff, or just some functions, templates? And how to organize them? In EPB? or just common python code or modules?

--
I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliSpot <<UliPad Snippets>>: http://ulipad.appspot.com
My Blog: http://www.donews.net/limodou

Massimo Di Pierro

unread,
May 18, 2008, 10:11:12 PM5/18/08
to web...@googlegroups.com
Hi Limodou,

about sharing views: You currently can. Say that in a controller you want to use a view called "default/index.html" from another app "other" you just type:

     response.view='../../other/views/default/index.html'

I did not know about func_globals. I am sure there are ways it can be used to improve web2py. I do not like the idea of adding a decorator to every function. I like the second suggestion better but I need to think about it. Perhaps there is a way to do something like it that does not break backward compatibility. Let's keep thinking.

About your framework. I see you went the route of using a number of existing components. It is interesting and you chose excellent components. When I made web2py my goal was to build everything from scratch since I needed it for teaching the inner workings and therefore needed to understand every little detail.

I do know the answers to your final questions. We can already share modules. I think we need to write specs for applications that cooperate. I have been experimenting with this a lot these days. I think one way to achieve it is by making apps more modular and having strict specs on how these modules should look like.

Massimo

limodou

unread,
May 18, 2008, 10:39:28 PM5/18/08
to web...@googlegroups.com
On Mon, May 19, 2008 at 10:11 AM, Massimo Di Pierro <mdip...@cs.depaul.edu> wrote:
Hi Limodou,

about sharing views: You currently can. Say that in a controller you want to use a view called "default/index.html" from another app "other" you just type:

     response.view='../../other/views/default/index.html'

Good for this. But if we can make it easier. We can  write view='<app>/<controller>/<function>.html',  that's easier  I think.

I did not know about func_globals. I am sure there are ways it can be used to improve web2py. I do not like the idea of adding a decorator to every function. I like the second suggestion better but I need to think about it. Perhaps there is a way to do something like it that does not break backward compatibility. Let's keep thinking.

About your framework. I see you went the route of using a number of existing components. It is interesting and you chose excellent components. When I made web2py my goal was to build everything from scratch since I needed it for teaching the inner workings and therefore needed to understand every little detail.

I do know the answers to your final questions. We can already share modules. I think we need to write specs for applications that cooperate. I have been experimenting with this a lot these days. I think one way to achieve it is by making apps more modular and having strict specs on how these modules should look like.

Yes, I think making apps more modular is easy to reuse them.

Massimo Di Pierro

unread,
May 19, 2008, 12:27:29 AM5/19/08
to web...@googlegroups.com
On May 18, 2008, at 9:39 PM, limodou wrote:

On Mon, May 19, 2008 at 10:11 AM, Massimo Di Pierro <mdip...@cs.depaul.edu> wrote:
Hi Limodou,

about sharing views: You currently can. Say that in a controller you want to use a view called "default/index.html" from another app "other" you just type:

     response.view='../../other/views/default/index.html'

Good for this. But if we can make it easier. We can  write view='<app>/<controller>/<function>.html',  that's easier  I think.

Right now is assumes the path starts under os.path.join(request.folder,'views')
It cannot be exactly '<app>/<controller>/<function>.html' because views hierarchy does not need to match controller function hierarchy (extend, include) but perhaps we could have something like

'~app/'  been replaced by '../../app/views/' and something starting with '/' been interpreted as an absolute path in the filesystem. If it work for you could you write a patch?

Massimo

carlo

unread,
May 19, 2008, 3:46:29 AM5/19/08
to web2py Web Framework
three things unrelated:

1- the big problem of the Python world compared to Java has one name:
Too many frameworks and none mature enough. Just to say: let's try to
make it one perfect not hundreds incomplete.

2- I like limodou's solution 1 with decorator

3- if views and controllers were just plain python modules would not
it be much easier? Is really meaningful elaborating strange
specifications for reusable components just for back compatibility? I
know that back compatibility is in the web2py chart but does it make
really sense when the installed application base is so small?

carlo

fpp

unread,
May 19, 2008, 5:24:57 AM5/19/08
to web2py Web Framework
I have no idea if this is realistic and doable, but from an end-user
point of view I would prefer the best of both worlds, ie something
that doesn't break compatibility (or, more importantly, twist web2py's
original "philosophy"), yet allows sharing stuff between apps without
putting too much burden on the developer through heavy formalism or
conventions.

I know it's a tall order, but could it not be achieved by adding an
API layer ? By analogy with SQLFORM and SQLTABLE, we could have a new
APP() call (or WAPP or whatever) that takes a web2py application name
as a parameter, as in : ext_app = APP('another_app_than_this_one').

Then the resulting object's methods and attributes could expose that
app's contents to the calling one, like :
ext_app.db()
ext_app.session()
ext_app.view()
ext_app.controller()
ext_app.module()
etc. ...

If it could be done, existing apps that don't use the new API would
carry on as before, and those who need inter-application sharing would
be able to do it in a fairly "web2pythonic" way. One could even
imagine it working between apps on two different web2py servers (using
pyro or something like that), but I guess that's a different story
again :-)

voltron

unread,
May 19, 2008, 5:44:08 AM5/19/08
to web2py Web Framework
I like the EPB idea, this seems to be one step in the direction of
code re-usability. I really dont like the idea of decorators because I
saw how they were used in Django and Pylons, some decorators were sort
of "magical" oudated or one had to dig up in several modules to see
exactly what is is doing. Are you suggestion this a s a replacement
for the workaround which we are doing now be defining and "init"
appliance to hold global data like databases for data interchange? If
this would mean that I would have to code my Auth module as a bean to
be used in an application that consists of several appliances I think
ist a very good idea . I have a few questions, I have no idea how they
apply since I am just thinking out loud, they might not make sense :-)

1. Would one be able to load beans without restarting the
application(web2py)?
2. Would it be feasible to strive for commercial EP beans just as in
byte compiled appliances?
3. How would changes to a certain bean affect the appliance as a
whole?
4. Where and how would tickets be generated?

That all I can ramble about for now. I know I might sound like a
broken record and Massimo would roll his eyes to the ceiling:-)), but
I am still very concerned with scaling issues. Using an exotic
filesystem that might not be portable is not an option. How would
these beans react when trying to scale using different database
connections? I really think that there should be an option to store
all the stuff(tickets too) that gets written to the filesystem in a
database

I hope I did not ramble and talk too much nonesense :-)

Miguel Lopes

unread,
May 19, 2008, 7:29:38 AM5/19/08
to web...@googlegroups.com
Humm, somehow I keep on having the idea that "Python Beans" should be named "Python Bytes"!
Best regards,
Miguel

limodou

unread,
May 19, 2008, 7:39:07 AM5/19/08
to web...@googlegroups.com
I also agree on shared configuration, that's very important for sharing . And I also think for shared configuration, we can think if default, and each app also can has its own config, so each app can test if an option has already in shared configuration, if not existed, it'll use its own config.

And for app independence, if one want to combine multiple apps into one project, so some apps may not run as a standalone application.

voltron

unread,
May 19, 2008, 8:04:24 AM5/19/08
to web2py Web Framework
hehe, I like that, Python bytes :-)

Massimo Di Pierro

unread,
May 19, 2008, 9:04:47 AM5/19/08
to web...@googlegroups.com

On May 19, 2008, at 4:44 AM, voltron wrote:

>
> I like the EPB idea, this seems to be one step in the direction of
> code re-usability. I really dont like the idea of decorators because I
> saw how they were used in Django and Pylons, some decorators were sort
> of "magical" oudated or one had to dig up in several modules to see
> exactly what is is doing. Are you suggestion this a s a replacement
> for the workaround which we are doing now be defining and "init"
> appliance to hold global data like databases for data interchange? If
> this would mean that I would have to code my Auth module as a bean to
> be used in an application that consists of several appliances I think
> ist a very good idea . I have a few questions, I have no idea how they
> apply since I am just thinking out loud, they might not make sense :-)
>
> 1. Would one be able to load beans without restarting the
> application(web2py)?

yes

> 2. Would it be feasible to strive for commercial EP beans just as in
> byte compiled appliances?

yes

> 3. How would changes to a certain bean affect the appliance as a
> whole?

It depends. This is why we need specifications. It should not affect
the appliance.

> 4. Where and how would tickets be generated?

Nothing changes.

> That all I can ramble about for now. I know I might sound like a
> broken record and Massimo would roll his eyes to the ceiling:-)), but
> I am still very concerned with scaling issues. Using an exotic
> filesystem that might not be portable is not an option. How would
> these beans react when trying to scale using different database
> connections? I really think that there should be an option to store
> all the stuff(tickets too) that gets written to the filesystem in a
> database

right now the only thing you cannot store in the database are
tickets. The reason is that (when in production, in my experience) it
is often the database to case the tickets. The Beans do not have any
special behavior here, you can store them in the DB right now.

> I hope I did not ramble and talk too much nonesense :-)

No. makes sense.

Massimo Di Pierro

unread,
May 19, 2008, 1:17:50 PM5/19/08
to web...@googlegroups.com
In my view....

The main weakness of other frameworks is that they are constantly
under development.
Improving and bug fixing is good but constantly changing the API is
very bad because forces to rewrite code, documentation, and
ultimately limits adoption. It is also a symptom that the software
had a bottom-up design vs a top-down design. In other words the
software lacks design.

Web2py has a top-down design. First I designed how I expected users
to user and which API i wanted to expose and how. I wanted it to work
as much Rails but in Python, without configuration files, with the
additional features that Django provides and Rail doesn't. I also
wanted to develop everything from scratch since I realized it was
important to understand every detail of how it works.

In the design I adopted the following principles:

- make is as easy as possible to newbies, even if occasionally at
the expense of making it "different" to experienced python
programmers. Example: no import, no decorators, controller functions
are not wrapped in classes, etc.
- make it as fast as possible, even at the expenses of some oddities
in code (for example the templates are translated into python code
using regex instead of a parser).
- make it as lean as possible. Have you heard the "Pareto Rule" in
business? http://en.wikipedia.org/wiki/Pareto_principle
- try to force developers (as much as possible) to follow good SE
principles.

I realize some of it features may not be the best option for
everybody but I am going be inflexible about not breaking backward
compatibility.
There is no way I can please everybody and it took a long way yo get
where we are in terms of users.

There are two issues that have been brought up and they are different
issues:
1) have one app been able to access components of another app
2) building projects made of multiple apps.
Let me discuss every one of them in detail:

1)
Currently apps can share sessions and databases.
One app can also use the views from another app (you may not like the
syntax but it works). Anyway I do not think this is a good idea.
I have no objection to create an API to share models (which you can
already do using execfile) but bare in mind that this will affect the
portability of applications.
The only real issue is controllers. Controllers are not modules for a
reason: like in Rails they can contain authentication code outside
functions. Moreover web2py needs to write on this files using meta-
programming in order to to provide web based testing capabilities.
From an SE point of view I feel that you need to reuse a controller
you are doing something wrong: either you are putting in a controller
something that belongs to a module, or you should expose the
controller function as a service. Changing web2py to allow one app
to call a controller function from another app will result in a
maintenance nightmare for your application and I do not want to
encourage it.

2)
I am all for it but this is not a technical problem. The issue here
is writing specs. It also boils down to people having different
definitions for projects and applications and what is atomic and what
is not.

For example I tend to code an app with multiple controllers and
multiple models that share the same names (modes/auth.py and
controllers/auth.py) . In this way the app is the project (in some
people language) and auth is a component. I write auth to be reusable.

**I define an app as a set of models/views/controllers that does not
need other apps installed locally in order to run**

For example an app may need an authentication app to run but the
authentication app may be a web service running somewhere else. If
you make an app dependent on another app at the filesystem level you
may run into scalability issues because you will be unable to
distribute your apps and your apps will not be very portable nor
easily reusable.

Both issues 1) and 2) boil down to the fact that there are no
specification on how to write portable apps and reusable components.
The idea of PythonBeans was to write such specifications and create
small components can people can reuse, share among apps and share
over the network without creating problems.

It is always possible that I am not understanding what some of you
are saying. Perhaps you should send me example of shared/cooperative
apps that you have written or are planning to use or why you would
ever want to call the code in the controller of another app.

Massimo

voltron

unread,
May 19, 2008, 1:41:54 PM5/19/08
to web2py Web Framework
Hmm, I think it would be faster to just kick start Enterprise Python
'Bytes' and add specs as we go otherwise we could discuss this
forever. Maybe using a complete app as a "container" for globally
available data is overkill and not the way to go. Maybe EPBs are
needed as you, say, to create another level of atomicity or glue
between apps. Please explain more on how it could be used, the more I
think about , the more i like the idea

fpp

unread,
May 19, 2008, 4:46:43 PM5/19/08
to web2py Web Framework
On 19 mai, 19:17, Massimo Di Pierro <mdipie...@cs.depaul.edu> wrote:
>
> In the design I adopted the following principles:
>
> - make is as easy as possible to newbies, even if occasionally at
> the expense of making it "different" to experienced python
> programmers. Example: no import, no decorators, controller functions
> are not wrapped in classes, etc.
> - make it as fast as possible, even at the expenses of some oddities
> in code (for example the templates are translated into python code
> using regex instead of a parser).
> - make it as lean as possible. Have you heard the "Pareto Rule" in
> business?http://en.wikipedia.org/wiki/Pareto_principle
> - try to force developers (as much as possible) to follow good SE
> principles.

From my very modest (but longish) experience I can attest that points
1, 3 and 4 are a definite success.
As I already wrote earlier, I made many half-hearted attempts at
"simple" Python web frameworks over the years, and web2py is certainly
the easiest I've seen, compared to the functionality it packs. Its
leanness is certainly part of that. And it did lead me to change some
bad old practices, which was a bit confusing initially but not enough
of a learning curve to drive me away, and certainly for the better
afterwards.

For me, web2py is what Zope could/should have been ten years ago, if
only it had been made accessible to mere mortals.

Point 2 (speed) is still in debate ; on a "normal" machine (PC/server)
web2py is certainly fast enough, but on small platforms (Zaurus/Nokia)
it is more sluggish between pages than lighter frameworks like
Snakelets or webpy.
I believe it is due to the database and speed of writing to Flash
memory. I haven't found how to disable the http server logging yet,
that may speed it up a bit.

I also like "Python bites" a lot - "Beans" sounds too much like Java
anyway :-)

Massimo Di Pierro

unread,
May 19, 2008, 5:05:23 PM5/19/08
to web...@googlegroups.com
My heart likes "bytes" more than "beans" but remember that we we are
targeting Django users, we are trying to convert Java users (and for
their own good).
If you say Enterprise Python Beans people understand what it means.
Bytes make people think about data, instead of code.

Massimo

Chris Leonello

unread,
May 19, 2008, 5:38:58 PM5/19/08
to web2py Web Framework
Hi Massimo,

Your EPB's as you've outlined them are a great idea. It seems much of
this thread is more about ancillary issues that are related but not
necessarily core to EPB's.

Concerning some of the "ancillary" discussion, you mention:

>For example I tend to code an app with multiple controllers and
>multiple models that share the same names (modes/auth.py and
>controllers/auth.py) . In this way the app is the project (in some
>people language) and auth is a component. I write auth to be reusable.

What is your mechanism for reusability in this case? Since
controllers and models are not objects or even in a module, I can't
instantiate a new one or inherit from one or import one.

You also mention:

>From an SE point of view I feel that you need to reuse a controller
>you are doing something wrong...

This seems to contradict your other statement. I'm just trying to
understand your design pattern so I can better use web2py. As you
mention, web2py does things differently than other frameworks (for
good reasons). Developers then have to unlearn some of the patterns
they have grown accustomed to.

Massimo Di Pierro

unread,
May 19, 2008, 5:44:29 PM5/19/08
to web...@googlegroups.com

On May 19, 2008, at 4:38 PM, Chris Leonello wrote:

>
> Hi Massimo,
>
> Your EPB's as you've outlined them are a great idea. It seems much of
> this thread is more about ancillary issues that are related but not
> necessarily core to EPB's.
>
> Concerning some of the "ancillary" discussion, you mention:
>
>> For example I tend to code an app with multiple controllers and
>> multiple models that share the same names (modes/auth.py and
>> controllers/auth.py) . In this way the app is the project (in some
>> people language) and auth is a component. I write auth to be
>> reusable.
>
> What is your mechanism for reusability in this case? Since
> controllers and models are not objects or even in a module, I can't
> instantiate a new one or inherit from one or import one.

I am thinking of cas modules/controllers/views. I either expose them
and access as services or copy the files in any app then needs stand
alone authentication.
By reusability of controller functionality I do not mean importing
since controllers are associated to a request object and a URL.


> You also mention:
>
>> From an SE point of view I feel that you need to reuse a controller
>> you are doing something wrong...
>
> This seems to contradict your other statement.

You are right. What I mean here is reuse in the sense of importing,
as other people have requested.

> I'm just trying to
> understand your design pattern so I can better use web2py. As you
> mention, web2py does things differently than other frameworks (for
> good reasons). Developers then have to unlearn some of the patterns
> they have grown accustomed to.

I agree.

fpp

unread,
May 19, 2008, 6:10:56 PM5/19/08
to web2py Web Framework
On 19 mai, 23:05, Massimo Di Pierro <mdipie...@cs.depaul.edu> wrote:
> My heart likes "bytes" more than "beans" but remember that we we are
> targeting Django users, we are trying to convert Java users (and for
> their own good).
> If you say Enterprise Python Beans people understand what it means.
> Bytes make people think about data, instead of code.

That's why I like "Bites", not "Bytes" : "bite" is like "snippet", so
more related to code, and much more fun associated with "Python" :-)

Massimo Di Pierro

unread,
May 19, 2008, 6:17:29 PM5/19/08
to web...@googlegroups.com
Yes that's better. I still think we should exploit Sun's maketing
machine.
You go to a company and they tell you they use java because it has
beans. You can say "we have them too" or "we call them Bites". In the
second case you have a lot more to explain.

Massimo

Chris Leonello

unread,
May 19, 2008, 6:20:37 PM5/19/08
to web2py Web Framework
Except "Python Bites" is not a complimentary phrase in colloquial
American English. Something synonymous with "bit" or "snippet" or
"fragment" might do better. Can't think of anything at the moment.

Massimo Di Pierro

unread,
May 19, 2008, 6:22:55 PM5/19/08
to web...@googlegroups.com
LMAO

Chris Leonello

unread,
May 19, 2008, 7:11:53 PM5/19/08
to web2py Web Framework
> I am thinking of cas modules/controllers/views. I either expose them
> and access as services or copy the files in any app...

I think your latter suggestion, copying files (or even parts of code)
can happen more often than it should because "traditional" methods of
importing or subclassing functionality are not available. I can see
novice programmers developing bad habits of copy/paste "reuse" to
create an unmaintainable common functionality among applications. The
framework design may inadvertently lead users to bad practices.

I'm not suggesting any change in web2py or it's philosophy. I
appreciate that a controller function is directly associated with a
url and a user request and, in that sense, importing or subclassing a
controller makes no sense. I like that web2py is fast. I like that
there is surprisingly little code and basically no dependencies to do
what it does. I need a few more months to really be a critic;-)

ygao

unread,
May 19, 2008, 8:13:42 PM5/19/08
to web...@googlegroups.com
On Tue, May 20, 2008 at 7:11 AM, Chris Leonello <chris.l...@gmail.com> wrote:

> I am thinking of cas modules/controllers/views. I either expose them
> and access as services or copy the files in any app...

I think your latter suggestion, copying files (or even parts of code)
can happen more often than it should because "traditional" methods of
importing or subclassing functionality are not available.  I can see
novice programmers developing bad habits of copy/paste "reuse" to
create an unmaintainable common functionality among applications.  The
framework design may inadvertently lead users to bad practices.
I totally agree above.see web2py appliance lib,several blog apps are just copying and pasting.
so if the real fact is this.don't say web2py is better than  django or any other framework.



--
※※※※※※※※※※※※※※※
http://BLOG.donews.com/ygao
UliPad:The powerful Python editor

ygao

unread,
May 19, 2008, 8:26:20 PM5/19/08
to web...@googlegroups.com
ok,that is my code.and the working example:
combine reveral app into one.
 
def get_controller(URI, env, *args, **kwag):
    environment={}
    for key in html.__all__: environment[key]=getattr(html,key)
    for key in validators.__all__: environment[key]=getattr(validators,key)
        
    environment['HTTP']=HTTP
    environment['redirect']=redirect
    environment['request']= request = env['request']
    temp = (request.application,request.controller, request.function)
    environment['response'] = response = env['response']
    environment['T']=translator(request)    
    environment['session'] = env['session']
    environment['cache'] = env['cache']
    environment['SQLDB']=SQLDB
    environment['SQLField']=SQLField
    environment['SQLFORM']=SQLFORM
    environment['SQLTABLE']=SQLTABLE
    environment['use_release'] = False
    environment['markdown']=markdown
   
    items=URI.split('/')
    request.application=items[0]
    request.controller=items[1]
    request.function=items[2]
   
    request.folder=os.path.join(request.env.web2py_path,'applications',request.application)+'/'
    SQLDB._set_thread_folder(os.path.join(request.folder,'databases'))
    if len(items) and items[-1]=='': del items[-1]
    if len(items)>3: items,request.args=items[:3],items[3:]
   
   
    run_models_in(environment, None)
    run_controller_in(request.controller,request.function,environment, None, 'get_controller')
    result = environment.get(request.function)(*args, **kwag)
    request.application,request.controller, request.function = temp
    return result

Massimo




Massimo Di Pierro

unread,
May 19, 2008, 8:54:51 PM5/19/08
to web...@googlegroups.com


This discussion is getting confusing. If you have code that should be reused put it in a module and import it (as with any other framework). If you have code that should not be reused put it in a controller. (web2py works as rails in this respect.) Please don't put code that should be reused in a controller and ask me to change web2py. If I were to do it web2py would get much more complex. For once you would have to call authentication functions in every controller function, you would have add a lot of imports, you would have to remember where functions are defined, you would have to add decorators to some functions, etc.

Example. If you are doing this in a controller

      def index():
            form=SQLFORM(db.table)
            if form.accepts(request.vars): response.flash='record inserted'
            return dict(form=form)

If you need to reuse index put it in a module:

      from gluon.sqlhtml import SQLFORM
      def reusable_index(request,response,db):
            form=SQLFORM(db.table)
            if form.accepts(request.vars): response.flash='record inserted'
            return dict(form=form)

and in the controller

      from applications.myapp.modules.mymodule import reusable_index
      def index(): return reusable_index(request,response,db)

the name of the exposed function 'index', the request,response and db objects have to be decoupled from the logic if you want to make it reusable. The role of the controller is to tie them together for one particular app. If you confuse these roles (the atomic functionality of reusable_index and the tie it all together controller) you run into serious problems.

What I meant to say about copying is this: if I make two apps for two distinct clients, even if they use the same module, even if I host both of them, I should to make a copy of the module because I have to package the apps separately for those clients. There is no shame.

web2py does not force you copy stuff. As you do with other frameworks you can install packages and modules and import them in your apps.

I think this discussion is not about importing (which you can do) but it boils down to a philosophic issue: whether modules belong to applications or belong to python. All frameworks assume they belong to python and if your app needs them you need to install the modules. web2py does not change this but I tried to introduce the concept of modules that belong exclusively to an application. This allow me to deploy the apps more easily because they have no dependences. I do not force it, I leave you the choice on how/where you put your modules.

I  like web2py better than other frameworks otherwise I would not have made it and I would not be spending time supporting it.
It is not perfect because perfection does not exist.

Massimo

Massimo Di Pierro

unread,
May 19, 2008, 9:02:59 PM5/19/08
to web...@googlegroups.com
I have no objection to your code below. I will be happy to include your function (or some version of it) in the standard API.
Anyway, as I always argued, anybody could use your function below without me changing web2py.

I do not want to tell you how you use web2py. I just want to defend the current design that allows you to do what you are doing.

Massimo

ygao

unread,
May 19, 2008, 9:08:10 PM5/19/08
to web...@googlegroups.com
On Tue, May 20, 2008 at 9:02 AM, Massimo Di Pierro <mdip...@cs.depaul.edu> wrote:
I have no objection to your code below. I will be happy to include your function (or some version of it) in the standard API.
Anyway, as I always argued, anybody could use your function below without me changing web2py.

I do not want to tell you how you use web2py. I just want to defend the current design that allows you to do what you are doing.

Massimo
 
ok,I'm so sorry to bother you.I don't bother you any more.

Massimo Di Pierro

unread,
May 19, 2008, 9:18:42 PM5/19/08
to web...@googlegroups.com
;-)

you don't bother me. These discussions are healthy!

Massimo

Massimo Di Pierro

unread,
May 20, 2008, 3:49:09 PM5/20/08
to web...@googlegroups.com
The more I read this....

...the more I like it and want to include it in web2py. Some
suggestions for improvement:

1) if URI starts with '/' do what you do; elif starts with 'http:'
call the controller remotely using urllib (and pass cookies form env)
2) after run_controller allow for the possibility of calling
run_view_in as an option.
3) what is temp (lines[-1])?
4) perhaps there should be a separate build_environment(env) somewhere
to make this leaner since it could me used in main as well.

Massimo

ygao

unread,
May 20, 2008, 11:01:57 PM5/20/08
to web...@googlegroups.com
are you sure?
 
 

1) if URI starts with '/' do what you do; elif starts with 'http:'
call the controller remotely using urllib (and pass cookies form env)
remotely ,I don't know how to do.

2) after run_controller allow for the possibility of calling
run_view_in as an option.
it can confuse the use?

3) what is temp (lines[-1])?
what?

4) perhaps there should be a separate build_environment(env) somewhere
to make this leaner since it could me used in main as well.
 
ok

Massimo


Massimo Di Pierro

unread,
May 21, 2008, 12:13:41 AM5/21/08
to web...@googlegroups.com
>
> 1) if URI starts with '/' do what you do; elif starts with 'http:'
> call the controller remotely using urllib (and pass cookies form env)
> remotely ,I don't know how to do.

I was thinking of something like:
1) For now I would call you function remote_run(url,env,...,view=True)
2) implement something like

if url[0]=='/':
do what you do...
if view: run_view as well
else: return urllib.urlopen(url).read()

I need to think more about cookies.

what do you think?

>
> 2) after run_controller allow for the possibility of calling
> run_view_in as an option.
> it can confuse the use?

Not necessarily.

> 3) what is temp (lines[-1])?
> what?

You use a variable temp that is not defined. Perhaps is just a cut-
and-paste problem.

ygao

unread,
May 21, 2008, 12:35:55 AM5/21/08
to web...@googlegroups.com
On Wed, May 21, 2008 at 12:13 PM, Massimo Di Pierro <mdip...@cs.depaul.edu> wrote:

>
> 1) if URI starts with '/' do what you do; elif starts with 'http:'
> call the controller remotely using urllib (and pass cookies form env)
> remotely ,I don't know how to do.

I was thinking of something like:
1) For now I would call you function remote_run(url,env,...,view=True)
2) implement something like

     if url[0]=='/':
          do what you do...
          if view: run_view as well
     else: return urllib.urlopen(url).read()

I need to think more about cookies.

what do you think?

 
I see ,that is best.

carlo

unread,
May 21, 2008, 8:02:10 AM5/21/08
to web2py Web Framework
really interesting stuff in your posts.
I like the EPB idea and the ygao code.

In my limited experience with web2py what I can say is what I miss
when I think of web2py code reusability.

I would like to reuse the same view with different controllers
(already addressed by Massimo) but preserving validation. This would
be my ideal path to MVC:

- in controllers, prepare data to be rendered (no Html here) i.e. a
form
- call my (shared) view passing the data
- make validation when form submitted

The fact no one needs here to outline this basic point about
reusability and MVC correct compliance, makes me think I do not yet
grasp the real power of the web2py architecture which can be really
plausible because of my limited experience ( after all I am just an
engineer not a programmer :-)
I am sure this is a subset of the EPB possibilities but I would ask
you how your code addresses my ingenuous request, forgive me if I am
inappropriate in this discussion.

carlo



On 21 Mag, 06:35, ygao <ygao2...@gmail.com> wrote:
> On Wed, May 21, 2008 at 12:13 PM, Massimo Di Pierro <mdipie...@cs.depaul.edu>

Massimo Di Pierro

unread,
May 21, 2008, 9:28:42 AM5/21/08