What framework to use with GAE?
Jonathan Ellis
using the built-in "webapp" framework. Is this accurate? I
personally don't see anything very compelling in the somewhat half-
baked django support or LAX, but I'm glad to be corrected. :)
-Jonathan
g-man
1. The default 'webapp' system is very basic, and it will run a
website, but it is bare-bones.
2. Django is a battle-tested framework that was developed for daily
use at an online newspaper site, so it has very many practical
features. It has been anointed by Guido, the creator of Python, who
now works for Google, and I understand the creators of Django have an
association with Google as well. You can watch Guido's video where he
goes into how to use Django, so that tells me 'why fight the trend?'
It takes care of many things for you, like form generation, error
management, etc, but there are some fine points related to integration
with subtle requirements of the App Engine that are not handled
perfectly yet. I followed the docs, articles, and used the 'helper',
plus studied the Django example to get my app running.
3. LAX has been designed by some smart people, and may be the ultimate
winner, but it is a little too complex for me to grasp right now;
perhaps with more tutorials, etc, it will rise up.
4. web2py is an excellent framework, the product of an eminently
pratical designer Computer Science professor), but I am not sure it is
totally plugged into the datastore at this time.
5. App Engine Oil is a new project that is also very simple and
practical, but it is only in the early stages of development.
6. Uliweb is another contender that is coming along nicely.
All of my opinions are based on working with Rails for over two years,
so I am comparing to that level of documentation, support, community,
books, videos, and usability. I have not worked with any of the other
frameworks around, but I do like Python as a language!
here is my learning app:
http://archi-checker.appspot.com
Jon Brisbin
HTML tags! ;) developer.
Thanks!
Jon Brisibn
http://jbrisbin.com
luismgz
Just take a loook at all the namespaces you have to import just to get
started, and all the directories and files you have to be aware of
when creating an application.
It may be the most comprehensive, but for many tasks it's like using a
cannon to kill a bird.
My personal favorite is "webpy".
It is very similar to webapp, the built-in gae framework, and
according to some GAE developers, it was the inspiration behind
webapp.
It is extremelly simple and comes with its own template
implementation, forms validation, sessions handling and a very simple
and poweerful database api (although it doesn't work in GAE).
Most of the times, all I need is only one script file and its
templates for creating a website.
The framework gets out of the way and lets you place files, images and
templates wherever you want, just as you would when creating a
conventional application.
It has a feature that creates the URL/controls automatically and I
feel it really reduces finger typing to its minimum expression.
To me, webpy is all about getting the job done in python with the
least delay, without having to learn any framework details or
particular idiosyncrasy.
Take a look here: http://webpy.org
Luis
g-man
Sylvain Thénault
--
Sylvain Thénault LOGILAB, Paris (France)
Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations
Développement logiciel sur mesure: http://www.logilab.fr/services
Python et calcul scientifique: http://www.logilab.fr/science
Johan Carlsson
http://code.google.com/p/play-py/
/Johan Carlsson
--
Johan Carlsson
Colliberty Easy Publisher
http://www.easypublisher.com
Waldemar Kornewald
On 7 Jul., 21:30, g-man <gregor...@gmail.com> wrote:
> 2. Django is a battle-tested framework that was developed for daily
> use at an online newspaper site, so it has very many practical
> features. It has been anointed by Guido, the creator of Python, who
> now works for Google, and I understand the creators of Django have an
> association with Google as well. You can watch Guido's video where he
> goes into how to use Django, so that tells me 'why fight the trend?'
> It takes care of many things for you, like form generation, error
> management, etc, but there are some fine points related to integration
> with subtle requirements of the App Engine that are not handled
> perfectly yet. I followed the docs, articles, and used the 'helper',
> plus studied the Django example to get my app running.
lines of code. If you read all the questions that come up on the
mailing list then almost always the answer is "look at Django" or
"look at Django's forms" or ... Seriously, very quickly you get to the
point where all those mini-frameworks fail.
Django 0.97 even provides auto-escaping in templates which makes it
*much* easier to write secure code. There are lots of reusable apps
which you could port to App Engine. The community is much bigger than
that of the smaller frameworks. Most of the source is MIT-licensed, so
if you take an existing project and build something much bigger with
it you're not *forced* to release it (note that our team still decided
to release some parts of our code: appenginepatch and ragendja).
> 3. LAX has been designed by some smart people, and may be the ultimate
> winner, but it is a little too complex for me to grasp right now;
> perhaps with more tutorials, etc, it will rise up.
serious and have designers in your team then you certainly don't want
them to write Python code. Even if you're a developer you probably
don't want to use stone-age print statements like this code snippet:
self.w(u'<h1>%s</h1>' % html_escape(entity.dc_title()))
Then, all code examples use a strange query language that looks like
hand-written SQL. An ORM would definitely be nice, so you don't have
to learn yet another language.
Finally, the license could be a show-stopper. LGPL and GPL just suck
if you don't want to release your source. You can't just take existing
code and modify it. You have to write everything yourself.
Don't get me wrong. Maybe in a few years LAX will become the next
super-framework, but currently it can't compete with Django.
Bye,
Waldemar Kornewald
--
appenginepatch: Makes Django just work
http://code.google.com/p/app-engine-patch/
nchauvat (Logilab)
> > 3. LAX has been designed by some smart people, and may be the ultimate
> > winner, but it is a little too complex for me to grasp right now;
> > perhaps with more tutorials, etc, it will rise up.
> They don't seem to have a template language. If you're doing anything
> serious and have designers in your team then you certainly don't want
> them to write Python code. Even if you're a developer you probably
> don't want to use stone-age print statements like this code snippet:
> self.w(u'<h1>%s</h1>' % html_escape(entity.dc_title()))
four years ago for it was too inefficient and cumbersome to use. I
take your message as a feature request to have it back in. We will try
to make it an urgent one, but the goal will only be to make sure users
are not considering it a show stopper. In actual production use, we
have found it much more productive to have designers use design tools,
developers use development tools and not make both use a tool
(templates) that is efficient for neither of them.
> Then, all code examples use a strange query language that looks like
> hand-written SQL.
SPARQL. Except that SPARQL did not exist when we started the project.
Having SPARQL has a query language has been in our backlog for years.
That RQL language is what is going to make a difference with django-
like frameworks for several reasons.
1/ accessing data is *much* easier with it. One can write complex
queries with RQL that would just be impossible to define or unreadable
using an object/filter suite of method calls.
2/ it offers an abstraction layers that allows to have a single
framework that runs on multiple back-ends. We have not published the
SQL backend yet (still working on separating it clearly from other
backends), but we already have components (pieces of schema and views)
that run both on SQL and AppEngine.
> An ORM would definitely be nice, so you don't have to learn yet another language.
allmyobjects = self.execute('Any X').entities()
The method entities() works on any resultset you get from a query.
Here is an example that assumes you wrote in your schema that there is
a "entry_of" relationship between BlogEntry and Blog. It gets all
blogs, then list entries using the ORM:
blogs = self.execute('Any X WHERE X is Blog').entities()
for blog in blogs::
print blog.reverse_entry_of
> Finally, the license could be a show-stopper. LGPL and GPL just suck
> if you don't want to release your source. You can't just take existing
> code and modify it. You have to write everything yourself.
that *if* you redistribute your application, you need to redistribute
it *and* the changes you made *and* the code _linked_ to it under the
GPL licence. LGPL says you only need to put under LGPL the changes you
made, not the code you linked to it.
LGPL might be a better choice than GPL for a framework. When we
decided to port this framework to AppEngine, we had no time to discuss
licence issues and went for the more conservative choice. But in my
book publishing a web site has nothing to do with redistributing
source code. I know a fair amount of companies using modified GPL code
for internal use. And someone could publish a LAX component under a
BSD licence for others to plug into a GPL framework without any
problem. The only thing we are trying to prevent here is someone
taking the framework and packaging it as closed source to his own
clients.
Sylvain Thénault
>
> On 8 juil, 12:01, Waldemar Kornewald <wkornew...@gmail.com> wrote:
> > > 3. LAX has been designed by some smart people, and may be the ultimate
> > > winner, but it is a little too complex for me to grasp right now;
> > > perhaps with more tutorials, etc, it will rise up.
>
> We definitely need to write more user documentation.
>
> > They don't seem to have a template language. If you're doing anything
> > serious and have designers in your team then you certainly don't want
> > them to write Python code. Even if you're a developer you probably
> > don't want to use stone-age print statements like this code snippet:
> > self.w(u'<h1>%s</h1>' % html_escape(entity.dc_title()))
>
> We had a template language engine hooked in. We removed it three or
> four years ago for it was too inefficient and cumbersome to use.
actually we didn't removed it, we simply stop using it. It's based on
SimpleTAL which is a pure python module so it should be usable within
appengine very quickly. Having support for the django template language
(or any other with pure python implementation, there are tons of them)
would probably be worth half a day of work though.
Roberto Saccon
what is the relation between your appengine django patch and the
"official" django helper ?
I your approach architecturally different, threrefore it can't be part
of django helper or is it more or less the same thing, but has more
features and you wanted the freedom to commit whatever and whenever
you want ?
regards
Roberto
Waldemar Kornewald
On 8 Jul., 14:43, Roberto Saccon <rsac...@gmail.com> wrote:
> Waldemar
>
> what is the relation between your appengine django patch and the
> "official" django helper ?
>
> I your approach architecturally different, threrefore it can't be part
> of django helper or is it more or less the same thing, but has more
> features and you wanted the freedom to commit whatever and whenever
> you want ?
For example, we don't want to use Google accounts, so we provide
Django's original auth framework. Also, we don't want to provide a
half-way emulation of Django's Model. It's impossible to fully emulate
the Model class, anyway.
Note that I'm currently discussing with Matt Brown from Google if and
how we can merge the Helper and appenginepatch into a single project.
Roberto Saccon
On Jul 8, 12:29 pm, Waldemar Kornewald <wkornew...@gmail.com> wrote:
> Hi Roberto,
>
> On 8 Jul., 14:43, Roberto Saccon <rsac...@gmail.com> wrote:
>
> > Waldemar
>
> > what is the relation between your appengine django patch and the
> > "official" django helper ?
>
> > I your approach architecturally different, threrefore it can't be part
> > of django helper or is it more or less the same thing, but has more
> > features and you wanted the freedom to commit whatever and whenever
> > you want ?
>
> Basically, yes. But there are also a few philosophical differences.
> For example, we don't want to use Google accounts, so we provide
> Django's original auth framework.
for a business app building around Google Apps for your Domains /
Google Docs / Gmail I would prefer to use Google accounts.
> Also, we don't want to provide a
> half-way emulation of Django's Model. It's impossible to fully emulate
> the Model class, anyway.
> Note that I'm currently discussing with Matt Brown from Google if and
> how we can merge the Helper and appenginepatch into a single project.
>
better, the Google branded helper will always receive broader
mainstream attention (and therefore possible better feedback on bugs)
Waldemar Kornewald
On 8 Jul., 12:50, "nchauvat (Logilab)" <nicolas.chau...@logilab.fr>
wrote:
> that *if* you redistribute your application, you need to redistribute
> it *and* the changes you made *and* the code _linked_ to it under the
> GPL licence. LGPL says you only need to put under LGPL the changes you
> made, not the code you linked to it.
bundle (comments, blog, etc.) then I'd have to publish them.
> LGPL might be a better choice than GPL for a framework. When we
> decided to port this framework to AppEngine, we had no time to discuss
> licence issues and went for the more conservative choice. But in my
> book publishing a web site has nothing to do with redistributing
> source code. I know a fair amount of companies using modified GPL code
> for internal use. And someone could publish a LAX component under a
> BSD licence for others to plug into a GPL framework without any
> problem. The only thing we are trying to prevent here is someone
> taking the framework and packaging it as closed source to his own
> clients.
to keep the modifications closed if the website isn't publicly
accessible, but only used within the company on a private server that
can't be reached from the Internet. Or did I misunderstand?
Bye,
Waldemar Kornewald
nchauvat (Logilab)
> Yes, but that was part of my point. If I modify one of the tools you
> bundle (comments, blog, etc.) then I'd have to publish them.
redistribute the code according to GPL-v2 and do not have to release
the source: http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#UnreleasedMods
"""A company is running a modified version of a GPL'ed program on a
web site. Does the GPL say they must release their modified sources?
The GPL permits anyone to make a modified version and use it without
ever distributing it to others. What this company is doing is a
special case of that. Therefore, the company does not have to release
the modified sources. [...]
> What does "internal use" mean? As far as I understand, it's only legal
> to keep the modifications closed if the website isn't publicly
> accessible, but only used within the company on a private server that
> can't be reached from the Internet. Or did I misunderstand?
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLRequireSourcePostedPublic
"""Does the GPL require that source code of modified versions be
posted to the public?
The GPL does not require you to release your modified version.
[...]"""
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#CanIDemandACopy
"""If I know someone has a copy of a GPL-covered program, can I demand
he give me a copy?
No. The GPL gives him permission to make and redistribute copies of
the program if he chooses to do so. He also has the right not to
redistribute the program, if that is what he chooses.
"""
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation
What is the difference between "mere aggregation" and "combining two
modules into one program"?
[...]
I hope this helps clearing up the matter. As for the license we are
using for LAX. We might change it to LGPL for the framework and use
something else for the components (LGPL, Apache2, BSD) if there is
popular demand. As I said, we took the more conservative route when
deciding to release it. If the only obstacle left to the use of LAX is
the license, we will work on it.
Chris L
Mike Orr
Hi Jonathan! Pylons runs on App Engine, and some of us are currently
testing it to find any edge cases it has in the App Engine
environment. Mako runs on App Engine, and Beaker has a Datastore
backend for storing sessions. I think Genshi and Jinja run on it now.
There are three main issues with App Engine, which affect any large
framework or application: the query restrictions, the 1000-file
limit, and the missing functions from the Python standard library.
The appengine-monkey package provides stubs for the missing functions,
which was necessary to get Setuptools and several template engines to
run on App Engine at all. The App Engine developers has belatedly
acknowledged that some of the missing functions are necessary
(especially the ast module), so hopefully we won't need the
monkeypatch someday, but they haven't said when.
Webapp is well thought-out and more flexible than it appears, but
you've got to provide a lot of stuff yourself: MVC structure, forms &
validation, etc. Having used (and liked) Quixote for a couple years,
I got tired of reinventing the wheel on the extras and not having a
standard or at least a few choices tested by my colleagues to go by.
But if you like minimal frameworks, Webapp is a pretty good choice.
My main problems with it:
- self.redirect() and self.error() do not raise exceptions to jump
immediately out of the handler, so you have to put if's around all the
following code, including anything that calls the function that did
the redirect/error.
- self.response is not WebOb even though self.request is.
- webapp.template is a kludgy extraction of Django templates
according to the docstring; it has to emulate global variables to use
it. It works but it makes me uncomfortable.
I like Pylons because it's pure WSGI from the ground up and designed
for interoperability, so it fits well with the App Engine paradigm and
with any third-party components you want now or may want in the
future. Plus the same application can theoretically run on App
Engine, another cloud server, or a traditional webhost. Well, that's
true for other frameworks too. I'm not sure how feasible it is to
make a portable app given the Datastore-centric nature of App Engine,
but that will come out with further research, and as we see what other
cloud companies offer to compete with App Engine. Anyway, my opinion
is Pylons is the most flexible non-minimal framework currently
available.
App Engine offers a subset of Django, and Guido seems to favor Django.
Probably most App Engine apps are being written with Django
currently. But it's still the very early days. To me it's not an
issue of which framework has the biggest market share but having
choices available. At least one monolithic framework (Django), a
mix-and-match framework (Pylons), and a minimalistic framework (Webapp
; maybe web.py) should be available.
I haven't had a chance to look at LAX but it may end up having its own
niche: a non-minimal framework built for App Engine. That may raise
issues if you later want to port your App Engine app elsewhere, but
maybe LAX will address that issue. The database layer from what I've
read provides more relational-like features. My first questions about
it are: is it reliable, and is the API too brand-new to be trusted?
Is it trying to do too much relational-like stuff that's ultimately
futile on BigTable? It may be perfectly reliable and robust in all
these regards; I just haven't had time to evaluate it for myself. But
these are the questions I would have in mind.
--
Mike Orr <slugg...@gmail.com>
Sylvain Thénault
> I haven't had a chance to look at LAX but it may end up having its own
> niche: a non-minimal framework built for App Engine. That may raise
> issues if you later want to port your App Engine app elsewhere, but
> maybe LAX will address that issue. The database layer from what I've
> read provides more relational-like features. My first questions about
> it are: is it reliable, and is the API too brand-new to be trusted?
> Is it trying to do too much relational-like stuff that's ultimately
> futile on BigTable? It may be perfectly reliable and robust in all
> these regards; I just haven't had time to evaluate it for myself. But
> these are the questions I would have in mind.
just to clafiry:
* LAX is the GAE version of our framework that we've been using
internally and for our customers for the past 5 years, it has not
been built specificly for GAE. We've just decided to take the
opportunity of the outcoming of GAE to release part of this
framework as free software. So the api is not really brand-new ;)
* we'll probably release in a near future the RDBMS backend so one can
write applications running on top the a relational database or on GAE
without changing one line of code (thanks to the RQL implementation
for the datastore)
* the RQL language has evolved in the past years, and is now a fully
featured language. The SQL implementation has been heavily used and
tested and is very robust and mostly bug free. Of course the datastore
implementation is more young, not complete and will be improved as
time goes, though this is already a good start much more powerful than
gql and all, and we're now writting real world applications to test
its effectivness.
nchauvat (Logilab)
> I haven't had a chance to look at LAX but it may end up having its own
> niche: a non-minimal framework built for App Engine. That may raise
> issues if you later want to port your App Engine app elsewhere, but
> maybe LAX will address that issue. The database layer from what I've
> read provides more relational-like features.
databases. The current LAX release (0.4) only features a datastore
backend, but we plan on releasing the SQL backend really soon now.
This will allow people to run the same code on AppEngine or on servers
they maintain. We will keep the LDAP and subversion backends for
ourselves as proprietary paying extensions for now.
> My first questions about it are: is it reliable, and is the API too brand-new to be trusted?
> Is it trying to do too much relational-like stuff that's ultimately
> futile on BigTable? It may be perfectly reliable and robust in all
> these regards; I just haven't had time to evaluate it for myself. But
> these are the questions I would have in mind.
http://lax.logilab.org/apidoc/ (the /robots.txt disallows search
engine access).
We have been using this framework for the past 7 years. We migrated
all our data for all our apps from one version to the next during all
that time. It takes some work to get a migration mechanism in a
framework, but I would say that this framework and its data-access
APIs are now stable.
As for LAX doing relational-like stuff that's not needed on AppEngine,
my answer is that we are not at the optimization stage yet. It took a
large amount of work to get the RQL->SQL compilation machinery to
ouput efficient SQL. I suppose it will take some work to get an
efficient version of "describe data using a high-level schema language
and have the framework generate a denormalized version that works best
with the datastore". We are working on a large-scale social-network
type application to make sure our framework works as well on the
datastore as it does on SQL databases.
We will release often and keep the group posted.
N. Rosencrantz
Mako: 1.10 ms
Cheetah:1.10 ms
Django: 2.74 ms
Myghty: 4.52 ms
Genshi: 11.46 ms
Kid: 14.54 ms
But Mako doesn't come with easy form validation, easy
internationalization/localization, custom authentication or session
management. Django seems have these features, but I won't use it since
it's too many files when I just need one or two more functions i.e.
form validation and internationalization/localization.
Niklas
On Jul 14, 10:20 pm, "nchauvat (Logilab)" <nicolas.chau...@logilab.fr>
wrote:
>
> > I haven't had a chance to look at LAX but it may end up having its own
> > niche: a non-minimal framework built for App Engine. That may raise
> > issues if you later want to port your App Engine app elsewhere, but
> > maybe LAX will address that issue. The database layer from what I've
> > read provides more relational-like features.
>
> It abstracts the storage backend so that apps can run on different
> databases. The current LAX release (0.4) only features a datastore
> backend, but we plan on releasing the SQL backend really soon now.
> This will allow people to run the same code on AppEngine or on servers
> they maintain. We will keep the LDAP and subversion backends for
> ourselves as proprietary paying extensions for now.
>
> > My first questions about it are: is it reliable, and is the API too brand-new to be trusted?
> > Is it trying to do too much relational-like stuff that's ultimately
> > futile on BigTable? It may be perfectly reliable and robust in all
> > these regards; I just haven't had time to evaluate it for myself. But
> > these are the questions I would have in mind.
>
Christopher Blunck
Django offering. I feel confined by the limitations of the template
system and it's inability to allow you to escape to pure python code
during HTML generation. I realize that comingling logic and
presentation is sacriligious to many but it often times offers great
opportunities for prototyping. If I'm sitting with a customer and I
can whip together some HTML and code snippits to get a proof of
concept in front of their face and we can evolve certain aspects of
the application working side by side. Django handicaps me by forcing
me to create custom filters or tags in order to achieve that level of
customization. I find that terribly limiting and immensely
frustrating.
I'm an architecture nazi that favors loosely coupled systems and I'll
be the first one to respond to the battle cry of "don't combine
application logic and presentation". But I'm also a pragmatist and
have seen how productive a collaborative session can be when a
framework assert itself between the developer and the customer.
Personally I think it's overzealous of the Django group to enforce
this restriction and a more palatable solution would have been to
provide some kind of flag that can be set at runtime that permits the
devilish behaviors I'm advocating (introducing some basic python logic
and looping into template rendering). This flag could be set to deny
such shenanigans in real systems but enabled at specific times to
allow for spike solutions to be developed.
Anyhow, I'll probably receive blistering responses proclaiming my
indecency as a result of this post.
Chris Marasti-Georg
I suppose I can turn this from a rant into something useful - Is there some way to do this in a django template that I can't figure out? If not, which other solution might give me this kind of functionality? Should I just create the list in my code and pass it to the template?
Jorge Vargas
>
> These are the benchmark numbers from www.makotemplates.org:
>
> Mako: 1.10 ms
> Cheetah:1.10 ms
> Django: 2.74 ms
> Myghty: 4.52 ms
> Genshi: 11.46 ms
> Kid: 14.54 ms
>
> But Mako doesn't come with easy form validation, easy
> internationalization/localization, custom authentication or session
> management. Django seems have these features, but I won't use it since
> it's too many files when I just need one or two more functions i.e.
> form validation and internationalization/localization.
>
it's a template language. all the features you are "missing" do not
belong in the template. That said, the replacements are babel, nothing
really as there is no https, and beaker.
Jorge Vargas
<christoph...@gmail.com> wrote:
>
> I'm using Django but as I grow my application I feel limited by the
> Django offering. I feel confined by the limitations of the template
> system and it's inability to allow you to escape to pure python code
> during HTML generation. I realize that comingling logic and
> presentation is sacriligious to many but it often times offers great
> opportunities for prototyping. If I'm sitting with a customer and I
> can whip together some HTML and code snippits to get a proof of
> concept in front of their face and we can evolve certain aspects of
> the application working side by side. Django handicaps me by forcing
> me to create custom filters or tags in order to achieve that level of
> customization. I find that terribly limiting and immensely
> frustrating.
>
plus for the pylons approach as you can use it's parts as needed, for
example I{m running an app that has the following components. GAE's
webapp (resquest,response and urls), mako (templates) , beaker (for
sessions), which is basically pylons without the paste stuff
Mike Orr
<christoph...@gmail.com> wrote:
> I'm an architecture nazi that favors loosely coupled systems and I'll
> be the first one to respond to the battle cry of "don't combine
> application logic and presentation". But I'm also a pragmatist and
> have seen how productive a collaborative session can be when a
> framework assert itself between the developer and the customer.
> Personally I think it's overzealous of the Django group to enforce
> this restriction and a more palatable solution would have been to
> provide some kind of flag that can be set at runtime that permits the
> devilish behaviors I'm advocating (introducing some basic python logic
> and looping into template rendering).
It's an age-old controversy, how much computational logic to allow in
templates. On a scale of 1-10 they look something like this:
0 - No logic allowed, only $placeholders and block begin/end
markers. The caller can manipulate
blocks to mimic 'if' and 'for'. The oldest PHP template system did this.
3 - Django: if/for/def allowed, but not expressions.
(Django-templates also has an extensive set
of built-in functions and an extension interface, which partly
make up for the lack of Python
code.)
5 - Genshi: if/for/def and Python expressions allowed, but not Python
statements.
8 - Mako: if/for/def, expressions, and arbitrary Python code allowed.
10 - All logic allowed: PHP is like this because the entire language
is embedded in HTML.
The second question to ask is, why are these engines that way? The
all-logic school wants to enable everything you might need because the
engine developers can't anticipate every situation. The no-logic
school believes that mixing logic and presentation is evil, and
envisions a dedicated
HTML designer distinct from the programmer. As time goes on more and
more functions are needed, which are implemented with a special syntax
to keep them "easier" or "different" than the underlying programming
language.
But the third question is, are these theories really true? Is it
right to judge programming logic based on the language it's written
in? (special template syntax = good, Python = maybe bad). Is a
certain preapproved construct better than an arbitrary one? Or does
the purpose of the logic matter more than the language or specific
construct? A growing number of Python template developers think it
does. The issue is to separate UI-related code from model/business
code, not to bless certain language constructs.
However, Python MVC frameworks have not quite evolved to the point of
having a Python view layer distinct from the Python controller layer
(i.e., a view method distinct from both the controller method and the
template). Still, you can do something similar in Mako/Cheetah by
putting the view code in the template or in a "Python template module"
used by the template. But even with that sometimes you put "view
logic" in the controller because it's just so computational you want
it in a normal Python method. E.g., preparing options for a select,
or data for table cells. I wonder if a controller action that calls a
"view action" that invokes the template might be a pattern worth
exploring.
--
Mike Orr <slugg...@gmail.com>
nchauvat (Logilab)
> having a Python view layer distinct from the Python controller layer
> (i.e., a view method distinct from both the controller method and the
> template).
* data-model / schema is defined in schema.py (or schema/*.py)
No logic ever gets mixed with the definition of the data model. Entity
definitions are purely declarative.
* domain-specific logic or "business objects" are defined in
entities.py (or entities/*.py)
If you have "Task todo_by Person" and each task has a workload and you
want to compute what is the total workload to be done by one person,
this is the place to define a get_total_workload() method on a person.
* presentation or views are defined in views.py (or views/*.py)
Views are applied to result sets containing entities that implement a
given interface. For example the calendar view from the standard
library can be applied to any result set of entities implementing the
calendar interface, even if all these entities are not of the same
type. In entities.py implement the calendar interface on your Task
class and all tasks become displayable with the standard calendar
view.
[In all of this, there is no template language. If you *really* want a
template language, you can call one in your custom view: you create
the object that contains the execution environment of your template,
then call the template engine to interpret the template within the
environment you set up.]
Since the only connection between views and entities are interface
names or entity names, does that fit you definition of "having a
Python view layer distinct from the Python controller layer" ?