Enterprise Python Beans (TM)
Massimo Di Pierro
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
mdipierro
> 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.
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.
continue to do so.
Massimo
limodou
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
limodou
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.
Massimo Di Pierro
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.
carlo
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
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
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
Best regards,
Miguel
limodou
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
Massimo Di Pierro
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
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
'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
>
> 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
> principles.
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
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
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.
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
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
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
> 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.
more related to code, and much more fun associated with "Python" :-)
Massimo Di Pierro
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
American English. Something synonymous with "bit" or "snippet" or
"fragment" might do better. Can't think of anything at the moment.
Massimo Di Pierro
Chris Leonello
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
> and access as services or copy the files in any app...
> I am thinking of cas modules/controllers/views. I either expose them
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.
--
※※※※※※※※※※※※※※※
http://BLOG.donews.com/ygao
UliPad:The powerful Python editor
ygao
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['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
Massimo Di Pierro
ygao
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
Massimo Di Pierro
Massimo Di Pierro
...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
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
Massimo Di Pierro
> 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
I was thinking of something like:
>
> 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.
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?
carlo
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
You can do this now
> 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
db=SQLDB(....)
db.define_table('person',SQLField('name',requires=IS_NOT_EMPTY()))
form=SQLFM(db.person) # in model or in controller
def test1():
response.view='form.html'
if form.accepts(request.vars,formname=None):
response.flash='inserted!'
return dict(form=form)
def test2():
response.view='form.html'
if form.accepts(request.vars,formname=None):
response.flash='inserted!'
return dict(form=form)
and if form.html
<html><body>
{{if response.flash;}}mind that: {{=response.flash}}<br/>{{pass}}
What is your name? <form><input name="name"/><input type="submit"/></
form>
{{if form.errors:}}errors: {{=BEAUTIFY(form.errors)}}<br/>{{pass}}
</body></html>
Is this that you were asking?
carlo
with one table (not useful in real life, a part from having a ready
form for the user to manage the db).
I would like:
db.define_table('clienti',SQLField('nome','string'),SQLField('cognome'))
db.define_table('purchases',SQLField('tipo','string'),SQLField('idcustomer',db.clienti))
db.purchases.idcustomer.requires=IS_IN_DB(db,db.clienti.id,'%
(cognome)s')
def test1():
data=db(db.purchases.idcustomer==db.clienti.id).select(db.clienti.nome,db.clienti.id)
return dict(data=data)
{{extend 'layout.html'}}
<h1>This is the default/test1.html template</h1>
{{form1=FORM(SELECT(_name='cliente',*[OPTION(data[i]
['nome'],_value=str(data[i]['id'])) for i in
range(len(data))]),INPUT(_type='submit'))}}
{{=form1}}
I want this because this way:
-you do not have any html in controller (now I noticed that in most of
the web2py applications I browsed, controllers have most of the Html
which is against MVC I suppose)
-I can reuse my view (maybe not in this trivial example) with a
different data set and I could have another controller which creates
its data set and reuse the same view
-more abstraction (again not much in this example): views just render
some data, no matter what they are.
The above code works. What you miss is the validation of form1 when
subsequently submitted (or this is what I know until now), again let
alone my basic example.
The reason for that is clear as you tried to explain it several times
(as far as I know).
From my point of view the above code is a plain (at minimum) example
of what an MVC supporter should expect: in my limited experience I
never put any html in TG controllers; even in Karrigell you can write
your services (the Karrigell "controllers") with no Html just invoking
a template+parameters.
I know that in Karrigell you do not have validation and in TG you have
a decorator to call for validation (from some examples I have seen, I
think the TG way is what I ask but not investigated much); what I like
to outline is that my view seems supported in other frameworks.
But here, I did not see much talking about this and everyone seems to
accept that if you want validation you must put your forms in
controllers. Or if you want a real MVC structure then you do not have
validation.
What's wrong with this?
carlo
voltron
trying to add forms to content coming from a database. This would help
in a CMS
content = """ bla bala content from a database %s """ % XML(form)
idea would be something like
content = """ bla bala content from a database %s """ % form
And the view would know what to do with a form object, one would write
the validation code only in the controller. Is this similar to what
you mean?
mdipierro
There is a logical problem here. The controller is executed before the
view. If you define something in the view (later) you cannot validate
it in the controller (earlier).
> {{extend 'layout.html'}}
> <h1>This is the default/test1.html template</h1>
> {{form1=FORM(SELECT(_name='cliente',*[OPTION(data[i]
> ['nome'],_value=str(data[i]['id'])) for i in
> range(len(data))]),INPUT(_type='submit'))}}
> {{=form1}}
1) You can do the validation in the view before {{=form1}}
> {{form1=FORM(SELECT(_name='cliente',*[OPTION(data[i]
> ['nome'],_value=str(data[i]['id'])) for i in
> range(len(data))]),INPUT(_type='submit'))}}
> {{=form1}}
But to me this is too close to PHP programming
2) you can refine the form in the controller so that it only contains
an association between variable names and validators but not
formatting information.
Do you have a different proposal? How would you want this done?
Massimo
mdipierro
Massimo Di Pierro
def test():
response.view='myview.html'
s=response.render(dict(... your variable...)
return s
Although this does not solve your problem.
Massimo
Chris Leonello
reusability called an Enterprise Python Bean. This fits right in with
a side project I am working on. A major part of this project was
going to be developing a "plug-in" architecture to add extensions to
the app. Then Massimo's post came along and solved that problem for
me.
The EPB proposal seems like a good template and use-case for me. I
will work from this and report back how it goes.
Massimo wrote:
>The question is how strict should the specifications be?
I'll have more feedback on an actual spec in a few days after fiddling
with the concept. My thought on specs is they should absolutely
define exactly what needs definition with utmost clarity and no
more ;-)
>...Any EJB expert here? I am not.
I am not either. To sum up what I know, which may not be accurate:
The JavaBeans spec is really fairly high level, defining a framework
for reusability. I think part of the spec is driven by the ability of
the bean to be used in a visual IDE, meaning it has to define certain
properties and methods so it can be used by one of those visual java
application builder software packages. It also has to define the
proper getter's and setter's for it's properties.
An Enterprise JavaBean is another beast. That spec has deals with
additional aspects of component communication, component containers
and management of components. It defines various types of beans like
the session bean, entity bean and message bean. I think a prime
driver for EJB was reusability among differing java systems and
frameworks.
>Because of the EJB analogies this has great marketing potential.
Given what I know about EJB (which may be completely incorrect), I
think the EPB is not very close to the EJB. We are really talking
about a web2py bean, or maybe a plug-in or extension architecture for
web2py. Correct me here, but wouldn't an EPB have to be defined by
the Python team as something reusable in any Python context which
implemented the EPB spec? Wouldn't an marketing potential in this
case be just...well...marketing?
>
>Can you think of applications? Possibly weird but useful applications.
>
I can think of many. If you look at the sample appliances on the
web2py site, imagine someone writing a bean for the chat app that put
user's avatars next to their comments. Or how about a graphing bean
for that movie rating app to plot the ratings?
When I have something mocked up I'll post my app or a link to a demo
or something. There is a difference between what I am focusing on and
the EPB suggestion, however. I was working out a plug-in
architecture, which usually implies dependence on a particular
application. An EPB would be application generic.
To be useful in an application agnostic way, however, the spec has to
be implemented on both ends, the app and the bean. That means that
apps will also have to be aware of the EPB spec if they want to use
EPB's. This is, from my understanding, part of the difference between
Enterprise JavaBeans and just JavaBeans. JavaBeans is a spec for
writing a reusable component. Part of the EJB spec is writing apps
that are built on Enterprise Beans.
I am very positive on the EPB, or whatever it will be called. I just
wanted to give my 2 cents, as usual.
Massimo Di Pierro
Right now the only problem I have (specifications aside) is with
serialization of the beans because of the database. That there are
two possibilities:
1) an object creates a SQLDB instance
2) an object uses a SQLDB instance defined outside
when the object is pickled if there is any reference to the SQLDB in
the object, the connection is serialized. When the object is unpicked
the connection is re-estabilished (both in case 1 and in case 2). The
fact is that in case 2 it should not because the connection was only
referenced, not "owned" by SQLDB.
This issue can be solved with strict specs on which beans can be
serialized or I need to implement a mechanism so that when an object
is unpicked check existing connections within the same thread. Can
make the code messy but it would a very smart bean.
Massimo
Chris Leonello
> user's avatars next to their comments. Or how about a graphing bean
> for that movie rating app to plot the ratings?
generally, "a bean that could be used in the xxx app" instead of " a
bean for the xxx app".
voltron
Here I was thinking again in my plug-in mindset, should be, more
generally, "a bean that could be used in the xxx app" instead of " a
bean for the xxx app".
newsletter bean that could be used with any app, but it does not
define its own tables but looks for certain tables in the host app
according to its own internal specs and uses them. Does this make
sense? I dont know anything about beans. Another question is, do we
need to really complicate things by imitation Java Beans? MAy a clean
plug-in API is sufficient. I know for sure that web2pys simplicity is
what drew most people here, like me.
Chris Leonello
> newsletter bean that could be used with any app, but it does not
> define its own tables but looks for certain tables in the host app
> according to its own internal specs and uses them. Does this make
> sense?
interface to make use of them. I don't think you want to spec out
that certain tables have to exist in the app to inter operate with
EPB's, though.
> sense? I dont know anything about beans. Another question is, do we
> need to really complicate things by imitation Java Beans? MAy a clean
> plug-in API is sufficient. I know for sure that web2pys simplicity is
> what drew most people here, like me.
JavaBeans are a much larger scope than what Massimo originally
presented. I like where he was going better. Maybe the comparison
with EJB is stretching it. Maybe not, I'm no EJB expert.
carlo
Though when you say "one would write the validation code only in the
controller" I suppose you should have a form in the controller which
is precisely what I do not want.
carlo
carlo
I will try 1, just for testing.
I am thinking about a proposal and I am studying your validation code.
Some questions:
1- someone can explain how validation is managed by TG? It seems that
@validate works the way I like but I am not sure: even in TG
controllers are executed before views?
2- I thought that another similar issue, let alone MVC strict
compliance, arises with validation via Ajax: suppose you have a form
you want to validate through an ajax request so invoking a different
controller. How could you that? I seem to understand you should pass
the form object to that controller..
carlo
Massimo Di Pierro
On May 22, 2008, at 4:03 AM, carlo wrote:
>
> yes I understand that problem is logical.
>
> I will try 1, just for testing.
>
> I am thinking about a proposal and I am studying your validation code.
> Some questions:
>
> 1- someone can explain how validation is managed by TG? It seems that
> @validate works the way I like but I am not sure: even in TG
> controllers are executed before views?
I think so. One cannot generate a view before knowing errors in the
input/
> 2- I thought that another similar issue, let alone MVC strict
> compliance, arises with validation via Ajax: suppose you have a form
> you want to validate through an ajax request so invoking a different
> controller. How could you that? I seem to understand you should pass
> the form object to that controller..
Ajax validation is done by the client. It can be done but it unsafe
and therefore a complement, not a replacement of the current mechanism.
carlo
about login validation, or validation against one RDBMS or many other
cases.
Suppose for a moment I would like to perform the same validation
form.accepts grants, so server-side, via an Ajax call (because for
example I wish to escape the page refesh), I think you could not with
the current web2py validation stack. This is, for my undestanding, the
same issue in a different view: you should pass a form object to
another controller to validate, but if you can do that even the above
mentioned controller-view issue would be solved because you could
invoke another controller to validate the form you rendered in the
current view. Something like:
(here I invent a _validate attribute)
def index():
form=FORM(_action='validate',_validate=True..............)
and the controller validate could perform the validation.
These trivial thoughts make me think: could be validation encapsulated
in a module function(FORM,parameters) so that any controller can call
it and validate the passed form?
Makes sense?
Carlo
Massimo Di Pierro
def index():
form=FORM(_action='validate',_validate=True..............)
and the controller validate could perform the validation.
These trivial thoughts make me think: could be validation encapsulated
in a module function(FORM,parameters) so that any controller can call
it and validate the passed form?
Makes sense?
carlo
>return(form=form)) but not with a form created in a view.
In a view the only way would be setting the form attribute
_action="another_controller_in_charge_of_validation" having the entire
form object sent in among the request.vars
I understand this is quite academic at the moment, but I think that
having a function you can pass to the form+field names to validate
would be more flexible.
Maybe in my summer homeworks..
carlo
Massimo Di Pierro
carlo
sent in the query string but then I have to make validation "by hand"
and not as form.accepts does.
A partial solution would be if I could use web2py validators against
one single field. Can you have something like:
if IS_NOT_EMPTY(x) AND IS_IN_SET(x,['max','john']):
do something
else:
something else
carlo
Massimo Di Pierro
(outside the function that serializes it) you can use it any other
controller function, including one designed only for validation. You
only need to tell the view (in jquery) to submit using ajax to the
validation controller.
voltron
version of this?
Thanks
carlo
controllers if you want to validate" issue.
Back to my unanswered question, can you have something like:
if IS_NOT_EMPTY(x) AND IS_IN_SET(x,['max','john']):
do something
else:
something else
carlo
Massimo Di Pierro
Massimo Di Pierro
IS_NOT_MEPTY is a class
IS_NOT_MEPTY(error_message='oops') is the validator object
IS_NOT_MEPTY()(value) calls the validator and returns (value,None) on
success and (value,error_message) on failure so.
Your code should be
> if IS_NOT_EMPTY()(x)[1]==None AND IS_IN_SET()(x,['max','john'])
> [1]==None:
> do something
> else:
> something else
Does it make sense?
Chris Leonello
connection string in beans, but you could just pass it in as an
argument. Even passing in an argument, I prefer to have the app in
control of all the db connections and not generating new ones for
every bean I load. I see that serialization becomes sticky...
On May 21, 10:54 pm, Massimo Di Pierro <mdipie...@cs.depaul.edu>
wrote:
Massimo Di Pierro
that be ok?
Massimo
Chris Leonello
> that be ok?
may not need tables). I like this better than accessing tables in the
app. That ties the bean much to closely to the app, although I see
nothing wrong with developing beans for specific applications if
desired.
Also, what if there is a need (security, integrity, ...) to isolate
some of the tables from bean access? I don't know if this is a real
concern or not.
carlo
and made some test with the shell.
At first sight I should say it is definitely possible to use the
validators 'stand-alone' so that you can validate single fields one at
a time.
After this 'discovery' I can preconfigure the following behaviour:
Scopes:
-declare your forms (Html or helpers) exclusively in Views (we do not
want any Html in controllers)
-validate your form fields
Procedure:
-via Ajax: using jQuery $.post('validator_controller',serialize(form))
so that in the validator_controller you have all the form fields in
request.vars. Now you can use the validator classes on each field.
-non Ajax: setting the _action attribute in your form you can submit
the fields to validate to the validator_controller.
carlo