Limitations of Django/webapp - any help before I jump ship to CherryPy?
15 views
Skip to first unread message
glenc
Jun 14, 2008, 10:55:26 AM6/14/08
to Google App Engine
Hi,
I'm prototyping a webapp on GAE now using the vanilla install and I'm
having a hard time with what seems to be some very fundamental
limitations of the underlying Django framework, and wanted to ask for
some suggestions before jumping to CherryPy (which I know well from
TurboGears development). I generally like to stick to the most
vanilla frameworks where possible as it means support for particular
problems is better, but alas:
1. I don't see any way to execute arbitrary Python from within a
Django template, i.e. there doesn't seem to be a {} structure that
allows you to write a little block of script that might set up some
variables or whatever. This means you have to do all of this in the
RequestHandler which makes template inheritance very annoying; AFAICS
you have to pass every variable through as a template parameter.
When you are working with template inheritance, even if you structure
your RequestHandlers to try do the "base template" stuff in a
superclass, you still have to worry about parameter name collision in
the dictionary passed to the template.
2. Django doesn't seem to want to let you call methods on variables
you have, e.g. if you pass through 'obj' as a template parameter,
Django is happy to let you access 'obj.property' but dies if you try
to call 'obj.method()' which means you have to set up convoluted
filters whose job it is to call the methods. Very bad for
readability.
3. Django doesn't seem to have any access to the normal Python
namespace, so let's say I want to insert the logged in user's email
address, doing something like {{ users.get_current_user().email() }}
won't work because 'users' is not in the Django namespace (and also
because Django doesn't understand method calls).
Any feedback on any of those concerns would be really appreciated, as
it's totally possible that I'm missing something and there are valid
workarounds that I'm not seeing. As I said, I would rather stick with
the vanilla framework if possible, however, as it stands, those
concerns are enough to make it worth it for me to use CherryPy instead
if there really aren't any workarounds.
I'm prototyping a webapp on GAE now using the vanilla install and I'm
having a hard time with what seems to be some very fundamental
limitations of the underlying Django framework, and wanted to ask for
some suggestions before jumping to CherryPy (which I know well from
TurboGears development). I generally like to stick to the most
vanilla frameworks where possible as it means support for particular
problems is better, but alas:
1. I don't see any way to execute arbitrary Python from within a
Django template, i.e. there doesn't seem to be a {} structure that
allows you to write a little block of script that might set up some
variables or whatever. This means you have to do all of this in the
RequestHandler which makes template inheritance very annoying; AFAICS
you have to pass every variable through as a template parameter.
When you are working with template inheritance, even if you structure
your RequestHandlers to try do the "base template" stuff in a
superclass, you still have to worry about parameter name collision in
the dictionary passed to the template.
2. Django doesn't seem to want to let you call methods on variables
you have, e.g. if you pass through 'obj' as a template parameter,
Django is happy to let you access 'obj.property' but dies if you try
to call 'obj.method()' which means you have to set up convoluted
filters whose job it is to call the methods. Very bad for
readability.
3. Django doesn't seem to have any access to the normal Python
namespace, so let's say I want to insert the logged in user's email
address, doing something like {{ users.get_current_user().email() }}
won't work because 'users' is not in the Django namespace (and also
because Django doesn't understand method calls).
Any feedback on any of those concerns would be really appreciated, as
it's totally possible that I'm missing something and there are valid
workarounds that I'm not seeing. As I said, I would rather stick with
the vanilla framework if possible, however, as it stands, those
concerns are enough to make it worth it for me to use CherryPy instead
if there really aren't any workarounds.
Roberto Saccon
Jun 14, 2008, 11:34:12 AM6/14/08
to Google App Engine
that is a django design decision: No python code in django templates.
Consider Django template language as language of its own, which has
nothing to do with Python.
and that is the way it should be (generally, I mean)
if your needs are different, use something else, there are no
workarounds, and if there would be, they would be considered as
security wholes or bugs and quickly fixed.
regards
--
Roberto Saccon
http://rsaccon.com
Consider Django template language as language of its own, which has
nothing to do with Python.
and that is the way it should be (generally, I mean)
if your needs are different, use something else, there are no
workarounds, and if there would be, they would be considered as
security wholes or bugs and quickly fixed.
regards
--
Roberto Saccon
http://rsaccon.com
glenc
Jun 14, 2008, 1:01:07 PM6/14/08
to Google App Engine
Ah OK that makes more sense now. While I respect the modularity (i.e.
in separation from an underlying script language) that Django is going
for, I think in practice this is just likely to cause me more
headaches that can be justified by an aesthetic preference for modular
code. Remember, these web frameworks are all about making development
easier + faster.
CherryPy + GAE, here I come :)
On Jun 14, 8:34 am, Roberto Saccon <rsac...@gmail.com> wrote:
> that is a django design decision: No python code in django templates.
> Consider Django template language as language of its own, which has
> nothing to do with Python.
>
> and that is the way it should be (generally, I mean)
>
> if your needs are different, use something else, there are no
> workarounds, and if there would be, they would be considered as
> security wholes or bugs and quickly fixed.
>
> regards
> --
> Roberto Sacconhttp://rsaccon.com
in separation from an underlying script language) that Django is going
for, I think in practice this is just likely to cause me more
headaches that can be justified by an aesthetic preference for modular
code. Remember, these web frameworks are all about making development
easier + faster.
CherryPy + GAE, here I come :)
On Jun 14, 8:34 am, Roberto Saccon <rsac...@gmail.com> wrote:
> that is a django design decision: No python code in django templates.
> Consider Django template language as language of its own, which has
> nothing to do with Python.
>
> and that is the way it should be (generally, I mean)
>
> if your needs are different, use something else, there are no
> workarounds, and if there would be, they would be considered as
> security wholes or bugs and quickly fixed.
>
> regards
> --
Sylvain
Jun 14, 2008, 1:01:56 PM6/14/08
to Google App Engine
You can call methods, remove the '()'
I posted a question about it :
http://groups.google.com/group/google-appengine/browse_frm/thread/2e52b93a320c1193
On 14 juin, 17:34, Roberto Saccon <rsac...@gmail.com> wrote:
> that is a django design decision: No python code in django templates.
> Consider Django template language as language of its own, which has
> nothing to do with Python.
>
> and that is the way it should be (generally, I mean)
>
> if your needs are different, use something else, there are no
> workarounds, and if there would be, they would be considered as
> security wholes or bugs and quickly fixed.
>
> regards
> --
> Roberto Sacconhttp://rsaccon.com
I posted a question about it :
http://groups.google.com/group/google-appengine/browse_frm/thread/2e52b93a320c1193
On 14 juin, 17:34, Roberto Saccon <rsac...@gmail.com> wrote:
> that is a django design decision: No python code in django templates.
> Consider Django template language as language of its own, which has
> nothing to do with Python.
>
> and that is the way it should be (generally, I mean)
>
> if your needs are different, use something else, there are no
> workarounds, and if there would be, they would be considered as
> security wholes or bugs and quickly fixed.
>
> regards
> --
nchauvat (Logilab)
Jun 14, 2008, 1:33:58 PM6/14/08
to Google App Engine
On 14 juin, 16:55, glenc <glen.coa...@gmail.com> wrote:
> I'm prototyping a webapp on GAE now using the vanilla install and I'm
> having a hard time with what seems to be some very fundamental
> limitations of the underlying Django framework, and wanted to ask for
> some suggestions before jumping to CherryPy (which I know well from
> TurboGears development). I generally like to stick to the most
> vanilla frameworks where possible as it means support for particular
> problems is better, but alas:
My humble opinion is that one needs a real language when doing
> I'm prototyping a webapp on GAE now using the vanilla install and I'm
> having a hard time with what seems to be some very fundamental
> limitations of the underlying Django framework, and wanted to ask for
> some suggestions before jumping to CherryPy (which I know well from
> TurboGears development). I generally like to stick to the most
> vanilla frameworks where possible as it means support for particular
> problems is better, but alas:
development (even if the ui runs in a web browser) and that template
languages are not real languages. I understand you want to stick to
vanilla frameworks and already know CherryPy, but if the Django-
partially-ported-on-AppEngine does not fit your needs and you find
templating languages limiting, I encourage you to invest some time in
the evaluation of http://lax.logilab.org (go right to ginco/web/views/
baseviews.py to get a feel of its view mechanism). LAX is about using
standard OOP techniques in Python instead of shoe-horning things in
template languages. Even macros can get difficult to use in template
languages (who would accept to use a programming language where
function calls would be difficult ?).
We have been pushing this framework to the front stage since AppEngine
came out and every person I showed it to at Google IO, including
AppEngine developers, made very positive comments about it.
I hope you'll like it. Please ask in this forum for help to get going
if you need some as several people in my company are reading it. As
for the documentation, we are currently working on it and publishing
new versions every two or three days. Feedback will be very welcome.
glenc
Jun 14, 2008, 1:44:44 PM6/14/08
to Google App Engine
Ah OK that's helpful, although I'm guessing there is no syntax to
support calling methods with arguments?
On Jun 14, 10:01 am, Sylvain <sylvain.viv...@gmail.com> wrote:
> You can call methods, remove the '()'
>
> I posted a question about it :http://groups.google.com/group/google-appengine/browse_frm/thread/2e5...
support calling methods with arguments?
On Jun 14, 10:01 am, Sylvain <sylvain.viv...@gmail.com> wrote:
> You can call methods, remove the '()'
>
Sylvain
Jun 14, 2008, 2:34:32 PM6/14/08
to Google App Engine
I don't think too. But i'm a python/django newbie.
so maybe, but i would be surprised.
Regards
so maybe, but i would be surprised.
Regards
kaksisa
Jun 14, 2008, 3:47:02 PM6/14/08
to Google App Engine
Calling methods with arguments is not allowed, however, you can create
custom filters and tags that provide the parametrized functionality
that you need.
http://www.djangoproject.com/documentation/templates_python/#extending-the-template-system
custom filters and tags that provide the parametrized functionality
that you need.
http://www.djangoproject.com/documentation/templates_python/#extending-the-template-system
glenc
Jun 19, 2008, 2:45:51 AM6/19/08
to Google App Engine
Just for anyone reference who hops on here and wants to know how to
get going with CherryPy and Genshi on GAE:
1. You need the patched version of CherryPy available from here:
http://boodebr.org/main/python/cherrypy-under-google-appserver
Hopefully this will be fixed in the final version of 3.1 but for now,
this is the way to go. Just extract it into your app directory.
2. Install Genshi with easy_install, then unzip the Genshi egg from
your site-packages directory into your app directory.
3. Make wonderful music :)
On Jun 14, 2:47 pm, kaksisa <kaks...@gmail.com> wrote:
> Calling methods with arguments is not allowed, however, you can create
> custom filters and tags that provide the parametrized functionality
> that you need.
>
> http://www.djangoproject.com/documentation/templates_python/#extendin...
get going with CherryPy and Genshi on GAE:
1. You need the patched version of CherryPy available from here:
http://boodebr.org/main/python/cherrypy-under-google-appserver
Hopefully this will be fixed in the final version of 3.1 but for now,
this is the way to go. Just extract it into your app directory.
2. Install Genshi with easy_install, then unzip the Genshi egg from
your site-packages directory into your app directory.
3. Make wonderful music :)
On Jun 14, 2:47 pm, kaksisa <kaks...@gmail.com> wrote:
> Calling methods with arguments is not allowed, however, you can create
> custom filters and tags that provide the parametrized functionality
> that you need.
>
>
> On Jun 14, 10:44 am,glenc<glen.coa...@gmail.com> wrote:
>
> > Ah OK that's helpful, although I'm guessing there is no syntax to
> > support calling methods with arguments?
>
> > On Jun 14, 10:01 am, Sylvain <sylvain.viv...@gmail.com> wrote:
>
> > > You can call methods, remove the '()'
>
> > > I posted a question about it :http://groups.google.com/group/google-appengine/browse_frm/thread/2e5...
>
> > > On 14 juin, 17:34, Roberto Saccon <rsac...@gmail.com> wrote:
>
> > > > that is a django design decision: No python code in django templates.
> > > > Consider Django template language as language of its own, which has
> > > > nothing to do with Python.
>
> > > > and that is the way it should be (generally, I mean)
>
> > > > if your needs are different, use something else, there are no
> > > > workarounds, and if there would be, they would be considered as
> > > > security wholes or bugs and quickly fixed.
>
> > > > regards
> > > > --
> > > > Roberto Sacconhttp://rsaccon.com
>
> On Jun 14, 10:44 am,glenc<glen.coa...@gmail.com> wrote:
>
> > Ah OK that's helpful, although I'm guessing there is no syntax to
> > support calling methods with arguments?
>
> > On Jun 14, 10:01 am, Sylvain <sylvain.viv...@gmail.com> wrote:
>
> > > You can call methods, remove the '()'
>
> > > I posted a question about it :http://groups.google.com/group/google-appengine/browse_frm/thread/2e5...
>
> > > On 14 juin, 17:34, Roberto Saccon <rsac...@gmail.com> wrote:
>
> > > > that is a django design decision: No python code in django templates.
> > > > Consider Django template language as language of its own, which has
> > > > nothing to do with Python.
>
> > > > and that is the way it should be (generally, I mean)
>
> > > > if your needs are different, use something else, there are no
> > > > workarounds, and if there would be, they would be considered as
> > > > security wholes or bugs and quickly fixed.
>
> > > > regards
> > > > --
> > > > Roberto Sacconhttp://rsaccon.com
>
Safa
Jul 29, 2008, 6:32:32 PM7/29/08
to Google App Engine
I've looked at extending tags, but it seems that there is no easy way
to extend the tags for the standard Django installed with Google
Apps. That's because the Django 'load' tag "looks at your
INSTALLED_APPS setting and only allows the loading of template
libraries within installed Django apps" (look under Extending the
Template System in this page
http://www.djangoproject.com/documentation/templates_python/#extending-the-template-system).
The only solution seems to be installing the entire Django framework.
Unless of course I'm wrong (which I hope I am). Any thoughts?
> that you need.
>
> http://www.djangoproject.com/documentation/templates_python/#extendin...
to extend the tags for the standard Django installed with Google
Apps. That's because the Django 'load' tag "looks at your
INSTALLED_APPS setting and only allows the loading of template
libraries within installed Django apps" (look under Extending the
Template System in this page
http://www.djangoproject.com/documentation/templates_python/#extending-the-template-system).
The only solution seems to be installing the entire Django framework.
Unless of course I'm wrong (which I hope I am). Any thoughts?
> Calling methods with arguments is not allowed, however, you can create
> custom filters andtagsthat provide the parametrized functionality
> that you need.
>
> http://www.djangoproject.com/documentation/templates_python/#extendin...
>
> On Jun 14, 10:44 am, glenc <glen.coa...@gmail.com> wrote:
>
> > Ah OK that's helpful, although I'm guessing there is no syntax to
> > support calling methods with arguments?
>
> > On Jun 14, 10:01 am, Sylvain <sylvain.viv...@gmail.com> wrote:
>
> > > You can call methods, remove the '()'
>
> > > I posted a question about it :http://groups.google.com/group/google-appengine/browse_frm/thread/2e5...
>
> > > On 14 juin, 17:34, Roberto Saccon <rsac...@gmail.com> wrote:
>
> > > > that is adjangodesign decision: No python code indjangotemplates.
> > > > ConsiderDjangotemplate language as language of its own, which has
> On Jun 14, 10:44 am, glenc <glen.coa...@gmail.com> wrote:
>
> > Ah OK that's helpful, although I'm guessing there is no syntax to
> > support calling methods with arguments?
>
> > On Jun 14, 10:01 am, Sylvain <sylvain.viv...@gmail.com> wrote:
>
> > > You can call methods, remove the '()'
>
> > > I posted a question about it :http://groups.google.com/group/google-appengine/browse_frm/thread/2e5...
>
> > > On 14 juin, 17:34, Roberto Saccon <rsac...@gmail.com> wrote:
>
> > > > that is adjangodesign decision: No python code indjangotemplates.
> > > > nothing to do with Python.
>
> > > > and that is the way it should be (generally, I mean)
>
> > > > if your needs are different, use something else, there are no
> > > > workarounds, and if there would be, they would be considered as
> > > > security wholes or bugs and quickly fixed.
>
> > > > regards
> > > > --
> > > > Roberto Sacconhttp://rsaccon.com
>
> > > > On Jun 14, 11:55 am, glenc <glen.coa...@gmail.com> wrote:
>
> > > > > Hi,
>
> > > > > I'm prototyping a webapp on GAE now using the vanilla install and I'm
> > > > > having a hard time with what seems to be some very fundamental
> > > > > limitations of the underlyingDjangoframework, and wanted to ask for
>
> > > > and that is the way it should be (generally, I mean)
>
> > > > if your needs are different, use something else, there are no
> > > > workarounds, and if there would be, they would be considered as
> > > > security wholes or bugs and quickly fixed.
>
> > > > regards
> > > > --
> > > > Roberto Sacconhttp://rsaccon.com
>
> > > > On Jun 14, 11:55 am, glenc <glen.coa...@gmail.com> wrote:
>
> > > > > Hi,
>
> > > > > I'm prototyping a webapp on GAE now using the vanilla install and I'm
> > > > > having a hard time with what seems to be some very fundamental
> > > > > some suggestions before jumping to CherryPy (which I know well from
> > > > > TurboGears development). I generally like to stick to the most
> > > > > vanilla frameworks where possible as it means support for particular
> > > > > problems is better, but alas:
>
> > > > > 1. I don't see any way to execute arbitrary Python from within a
> > > > >Djangotemplate, i.e. there doesn't seem to be a {} structure that
> > > > > TurboGears development). I generally like to stick to the most
> > > > > vanilla frameworks where possible as it means support for particular
> > > > > problems is better, but alas:
>
> > > > > 1. I don't see any way to execute arbitrary Python from within a
> > > > > allows you to write a little block of script that might set up some
> > > > > variables or whatever. This means you have to do all of this in the
> > > > > RequestHandler which makes template inheritance very annoying; AFAICS
> > > > > you have to pass every variable through as a template parameter.
>
> > > > > When you are working with template inheritance, even if you structure
> > > > > your RequestHandlers to try do the "base template" stuff in a
> > > > > superclass, you still have to worry about parameter name collision in
> > > > > the dictionary passed to the template.
>
> > > > > 2.Djangodoesn't seem to want to let you call methods on variables
> > > > > variables or whatever. This means you have to do all of this in the
> > > > > RequestHandler which makes template inheritance very annoying; AFAICS
> > > > > you have to pass every variable through as a template parameter.
>
> > > > > When you are working with template inheritance, even if you structure
> > > > > your RequestHandlers to try do the "base template" stuff in a
> > > > > superclass, you still have to worry about parameter name collision in
> > > > > the dictionary passed to the template.
>
> > > > > you have, e.g. if you pass through 'obj' as a template parameter,
> > > > >Djangois happy to let you access 'obj.property' but dies if you try
> > > > > to call 'obj.method()' which means you have to set up convoluted
> > > > > filters whose job it is to call the methods. Very bad for
> > > > > readability.
>
> > > > > 3.Djangodoesn't seem to have any access to the normal Python
> > > > > filters whose job it is to call the methods. Very bad for
> > > > > readability.
>
> > > > > namespace, so let's say I want to insert the logged in user's email
> > > > > address, doing something like {{ users.get_current_user().email() }}
> > > > > won't work because 'users' is not in theDjangonamespace (and also
> > > > > becauseDjangodoesn't understand method calls).
> > > > > address, doing something like {{ users.get_current_user().email() }}
> > > > > won't work because 'users' is not in theDjangonamespace (and also
Daniel O'Brien
Jul 29, 2008, 7:40:25 PM7/29/08
to Google App Engine
On extending, we deviate a bit from the standard Django approach,
replacing a few calls and removing the need for a "load" tag in your
template.
Basic example:
myfilters.py: """
from google.appengine.ext.webapp import template
register = template.create_template_register()
@register.filter
def cut(value, arg):
return value.replace(arg, '')
"""
main.py: """
from google.appengine.ext import webapp
from google.appengine.ext.webapp import template
class MainHandler(webapp.RequestHandler):
def get(self):
template.register_template_library('myfilters')
...
"""
The new filter "cut" should now be available in your templates without
needing to call "load." A similar approach should work for custom
tags.
Addressing one of glenc's earlier concerns regarding pulling from the
local namespace, one approach is to pass locals() into the template
renderer (e.g. "template.render(template_path, locals())"). Keep in
mind that exposing and relying on locals() can lead to some
interesting problem cases.
Daniel
On Jul 29, 3:32 pm, Safa <s...@alai.com> wrote:
> I've looked at extending tags, but it seems that there is no easy way
> to extend the tags for the standard Django installed with Google
> Apps. That's because the Django 'load' tag "looks at your
> INSTALLED_APPS setting and only allows the loading of template
> libraries within installed Django apps" (look under Extending the
> Template System in this pagehttp://www.djangoproject.com/documentation/templates_python/#extendin...).
replacing a few calls and removing the need for a "load" tag in your
template.
Basic example:
myfilters.py: """
from google.appengine.ext.webapp import template
register = template.create_template_register()
@register.filter
def cut(value, arg):
return value.replace(arg, '')
"""
main.py: """
from google.appengine.ext import webapp
from google.appengine.ext.webapp import template
class MainHandler(webapp.RequestHandler):
def get(self):
template.register_template_library('myfilters')
...
"""
The new filter "cut" should now be available in your templates without
needing to call "load." A similar approach should work for custom
tags.
Addressing one of glenc's earlier concerns regarding pulling from the
local namespace, one approach is to pass locals() into the template
renderer (e.g. "template.render(template_path, locals())"). Keep in
mind that exposing and relying on locals() can lead to some
interesting problem cases.
Daniel
On Jul 29, 3:32 pm, Safa <s...@alai.com> wrote:
> I've looked at extending tags, but it seems that there is no easy way
> to extend the tags for the standard Django installed with Google
> Apps. That's because the Django 'load' tag "looks at your
> INSTALLED_APPS setting and only allows the loading of template
> libraries within installed Django apps" (look under Extending the
Safa
Jul 29, 2008, 7:49:43 PM7/29/08
to Google App Engine
Answered my own question from another post on this group:
1. Follow exactly instructions on the Django website for writing a
custom tag (say tagmodule.py)
2. Place your tag module into a package:
Create directory (say tagspackage) & add empty file
__init__.py and tagmodule.py to the directory
3. Instead of using the Django 'load' tag, add this line immediately
after imports in main.py
webapp.template.register_template_library('tagpackage.tagmodule')
As simple as 1,2,3 ... it works.
On Jul 29, 5:32 pm, Safa <s...@alai.com> wrote:
> I've looked at extendingtags, but it seems that there is no easy way
> to extend thetagsfor the standardDjangoinstalled with Google
> Apps. That's because theDjango'load' tag "looks at your
> Template System in this pagehttp://www.djangoproject.com/documentation/templates_python/#extendin...).
1. Follow exactly instructions on the Django website for writing a
custom tag (say tagmodule.py)
2. Place your tag module into a package:
Create directory (say tagspackage) & add empty file
__init__.py and tagmodule.py to the directory
3. Instead of using the Django 'load' tag, add this line immediately
after imports in main.py
webapp.template.register_template_library('tagpackage.tagmodule')
As simple as 1,2,3 ... it works.
On Jul 29, 5:32 pm, Safa <s...@alai.com> wrote:
> I've looked at extendingtags, but it seems that there is no easy way
> to extend thetagsfor the standardDjangoinstalled with Google
> Apps. That's because theDjango'load' tag "looks at your
> INSTALLED_APPS setting and only allows the loading of template
> libraries within installedDjangoapps" (look under Extending the
> Template System in this pagehttp://www.djangoproject.com/documentation/templates_python/#extendin...).
Safa
Jul 29, 2008, 7:52:51 PM7/29/08
to Google App Engine
Oh yes ... on the dev environment don't forget to start & stop the web
app to get main to run again
On Jul 29, 6:49 pm, Safa <s...@alai.com> wrote:
> Answered my own question from another post on this group:
>
> 1. Follow exactly instructions on theDjangowebsite for writing a
app to get main to run again
On Jul 29, 6:49 pm, Safa <s...@alai.com> wrote:
> Answered my own question from another post on this group:
>
> custom tag (say tagmodule.py)
> 2. Place your tag module into a package:
> Create directory (say tagspackage) & add empty file
> __init__.py and tagmodule.py to the directory
> 3. Instead of using theDjango'load' tag, add this line immediately
> 2. Place your tag module into a package:
> Create directory (say tagspackage) & add empty file
> __init__.py and tagmodule.py to the directory
Reply all
Reply to author
Forward
0 new messages