Re: pylons 1.0 and possible redirect bug ?
On Jul 21, 5:56 am, huydo contactm...@gmail.com wrote: Hi, Just trying to do a direct from the __call__ method in my base.py file and this is the following exception which I am getting. redirect(url(controller='redirect', action='index')) File 'c:\\apps\\xbits\\ktrack\\python\\lib\\site-packages\\pylons-1.0- py2.5.egg\\pylons\\controllers\\util.py', line 208 in redirect raise exc(location=url).exception HTTPFound: 302 Found Content-Type: text/html; charset=UTF-8 Content-Length: 0 Location: /redirect/index Adding the following line to my middleware.py file (just after the #CUSTOM MIDDLE HERE) fixed it. app = httpexceptions.make_middleware(app) Is this a bug ? or am I doing something wrong ? I'd say it's more that you're doing something wrong. ;) redirect works by raising an exception (the one you're seeing). Normally, this would be caught by the base WSGIController class (in _inspect_call) and converted into an HTTP response, but because __call__ is a setup function and not part of the action context, the exception isn't caught, presumably by design. In other words, you should only use redirect from within the action context--either in __before__, a particular action method, or __after__. If you really want to redirect from __call__, you can create an instance of HTTPFound and return that from __call__. -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Returning a file object from an action
Hi everyone, I looked into the documentation, but couldn't find any mentioning of what I could return from an action. I know that I can return a string, most likely rendered from a template. Is it possible to return a file object from an action, so that the contents of the file will be delivered to receiving end? I need to pass images through a controller, because I need to check if the user is allowed to see the requested picture - so I can't make use of the Apache of delivering the files myself. Up until now, I've always read such files into memory, and just returned the contents, but these images might be a bit bigger than what I'm used to with dealing with, so this might be a useful function, to reduce memory usage on my app. Thanks in advance for any advice on this! Regards, Jens -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Returning a file object from an action
Hello, I think you want something like this. from paste.fileapp import FileApp # in controller #...in some action, get the path to serve wsgi_app = FileApp(path) return wsgi_app(request.environ, self.start_response) A better solution you might want to look into is x-sendfile/x-accel-redirect which let's you pass the path up to a proxying server via a header that it can use to serve the file. That way you can check permissions in your app but still serve the file via apache/nginx/etc. -Ian On Wed, Jul 21, 2010 at 12:27 PM, Jens Hoffrichter jens.hoffrich...@gmail.com wrote: Hi everyone, I looked into the documentation, but couldn't find any mentioning of what I could return from an action. I know that I can return a string, most likely rendered from a template. Is it possible to return a file object from an action, so that the contents of the file will be delivered to receiving end? I need to pass images through a controller, because I need to check if the user is allowed to see the requested picture - so I can't make use of the Apache of delivering the files myself. Up until now, I've always read such files into memory, and just returned the contents, but these images might be a bit bigger than what I'm used to with dealing with, so this might be a useful function, to reduce memory usage on my app. Thanks in advance for any advice on this! Regards, Jens -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.compylons-discuss%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Returning a file object from an action
On Wed, Jul 21, 2010 at 12:33 PM, Ian Wilson ianjosephwil...@gmail.com wrote: Hello, I think you want something like this. from paste.fileapp import FileApp # in controller #...in some action, get the path to serve wsgi_app = FileApp(path) return wsgi_app(request.environ, self.start_response) Yes, use paste.fileapp. You can just return the wsgi_app object directly, and Pylons will call it for you. A better solution you might want to look into is x-sendfile/x-accel-redirect which let's you pass the path up to a proxying server via a header that it can use to serve the file. That way you can check permissions in your app but still serve the file via apache/nginx/etc. This is a more efficient method which some of us are starting to use. -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Returning a file object from an action
On 2010-7-21 21:40, Mike Orr wrote: On Wed, Jul 21, 2010 at 12:33 PM, Ian Wilsonianjosephwil...@gmail.com wrote: Hello, I think you want something like this. from paste.fileapp import FileApp # in controller #...in some action, get the path to serve wsgi_app = FileApp(path) return wsgi_app(request.environ, self.start_response) Yes, use paste.fileapp. You can just return the wsgi_app object directly, and Pylons will call it for you. A better solution you might want to look into is x-sendfile/x-accel-redirect which let's you pass the path up to a proxying server via a header that it can use to serve the file. That way you can check permissions in your app but still serve the file via apache/nginx/etc. This is a more efficient method which some of us are starting to use. Would be nice if FileApp can do that automatically itself. Or does it already? Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Returning a file object from an action
Hi, On 21 July 2010 21:40, Mike Orr sluggos...@gmail.com wrote: On Wed, Jul 21, 2010 at 12:33 PM, Ian Wilson ianjosephwil...@gmail.com wrote: Hello, I think you want something like this. from paste.fileapp import FileApp # in controller #...in some action, get the path to serve wsgi_app = FileApp(path) return wsgi_app(request.environ, self.start_response) Yes, use paste.fileapp. You can just return the wsgi_app object directly, and Pylons will call it for you. OK, this sounds exactly like what I need. Thanks for the hint! A better solution you might want to look into is x-sendfile/x-accel-redirect which let's you pass the path up to a proxying server via a header that it can use to serve the file. That way you can check permissions in your app but still serve the file via apache/nginx/etc. This is a more efficient method which some of us are starting to use. This looks quite interesting, too, but I'm a bit concerned that I need to do it in dev (using paster) differently to doing it on production (apache/mod_wsgi). So, for the time being I'll probably stick with the FileApp (if Pylons 0.9.6.2 supports it, I just hope - you know, legacy pylons app ^^) But, if how Wichert mentioned, paster.FileApp could be configured to do that automatically (maybe with a switch in the ini file, and then triggering some sort of middleware), that would be great, too! Anyway, thanks for advice. Jens P.S. And I definitely know why I prefer the Pylons ML to the lists run by other frameworks, namely some Java web frameworks.Within minutes, I got a correct, useful and concise answer. You guys are really awesom! -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Returning a file object from an action
On Wed, Jul 21, 2010 at 1:03 PM, Jens Hoffrichter jens.hoffrich...@gmail.com wrote: Hi, On 21 July 2010 21:40, Mike Orr sluggos...@gmail.com wrote: On Wed, Jul 21, 2010 at 12:33 PM, Ian Wilson ianjosephwil...@gmail.com wrote: Hello, I think you want something like this. from paste.fileapp import FileApp # in controller #...in some action, get the path to serve wsgi_app = FileApp(path) return wsgi_app(request.environ, self.start_response) Yes, use paste.fileapp. You can just return the wsgi_app object directly, and Pylons will call it for you. OK, this sounds exactly like what I need. Thanks for the hint! A better solution you might want to look into is x-sendfile/x-accel-redirect which let's you pass the path up to a proxying server via a header that it can use to serve the file. That way you can check permissions in your app but still serve the file via apache/nginx/etc. This is a more efficient method which some of us are starting to use. This looks quite interesting, too, but I'm a bit concerned that I need to do it in dev (using paster) differently to doing it on production (apache/mod_wsgi). So, for the time being I'll probably stick with the FileApp (if Pylons 0.9.6.2 supports it, I just hope - you know, legacy pylons app ^^) But, if how Wichert mentioned, paster.FileApp could be configured to do that automatically (maybe with a switch in the ini file, and then triggering some sort of middleware), that would be great, too! That has been suggested recently. The main impediment is that Paste is in a feature slumber (freeze would be too strong a word). The main development work now is to spin off useful parts of Paste into their own packages. Still, if somebody wants to propose an API or patch for paste.fileapp, I'm sure the Paste list would be interested. One issue is that I think Apache and Nginx have completely different APIs for sending files, so the implementation would have to accommodate those servers and other future webservers. Also, logically if the webserver is handling FileApp files, it's also probably handing the public directory. Maybe Pylons could define a single configuration switch for both features. -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
pkg_resources barfing on pip requirements file format
When using paste, e.g. loadapp, it goes through
setuptools/pkg_resources, which goes through your app's requires.txt.
Any hacks to allow for pip requirements syntax?
(http://pip.openplans.org/requirement-format.html)
Currently if I try the following, for instance:
-f
http://protobuf-socket-rpc.googlecode.com/files/protobuf_socket_rpc-1.3.1.tar.gz
pkg_resources will barf trying to parse this:
File
/home/yang/env/lib/python2.6/site-packages/Pylons-1.0-py2.6.egg/pylons/test.py,
line 74, in begin
relative_to=path)
File
/home/yang/env/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
line 204, in loadapp
return loadobj(APP, uri, name=name, **kw)
File
/home/yang/env/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
line 224, in loadobj
global_conf=global_conf)
File
/home/yang/env/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
line 248, in loadcontext
global_conf=global_conf)
File
/home/yang/env/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
line 278, in _loadconfig
return loader.get_context(object_type, name, global_conf)
File
/home/yang/env/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
line 409, in get_context
section)
File
/home/yang/env/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
line 431, in _context_from_use
object_type, name=use, global_conf=global_conf)
File
/home/yang/env/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
line 361, in get_context
global_conf=global_conf)
File
/home/yang/env/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
line 248, in loadcontext
global_conf=global_conf)
File
/home/yang/env/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
line 278, in _loadconfig
return loader.get_context(object_type, name, global_conf)
File
/home/yang/env/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
line 409, in get_context
section)
File
/home/yang/env/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
line 431, in _context_from_use
object_type, name=use, global_conf=global_conf)
File
/home/yang/env/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
line 361, in get_context
global_conf=global_conf)
File
/home/yang/env/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
line 248, in loadcontext
global_conf=global_conf)
File
/home/yang/env/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
line 285, in _loadegg
return loader.get_context(object_type, name, global_conf)
File
/home/yang/env/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
line 561, in get_context
object_type, name=name)
File
/home/yang/env/lib/python2.6/site-packages/PasteDeploy-1.3.3-py2.6.egg/paste/deploy/loadwsgi.py,
line 581, in find_egg_entry_point
pkg_resources.require(self.spec)
File
/home/yang/env/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/pkg_resources.py,
line 666, in require
for callback in self.callbacks:
File
/home/yang/env/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/pkg_resources.py,
line 570, in resolve
only distributions that are in the project's plugin directory or
File
/home/yang/env/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/pkg_resources.py,
line 2149, in requires
for extra,reqs in split_sections(self._get_metadata(name)):
File
/home/yang/env/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/pkg_resources.py,
line 2143, in _dep_map
def _dep_map(self):
File
/home/yang/env/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/pkg_resources.py,
line 2436, in parse_requirements
File
/home/yang/env/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg/pkg_resources.py,
line 2404, in scan_list
iterable thereof.
ValueError: ('Expected version spec in', '-f
http://protobuf-socket-rpc.googlecode.com/files/protobuf_socket_rpc-1.3.1.tar.gz',
'at', '
http://protobuf-socket-rpc.googlecode.com/files/protobuf_socket_rpc-1.3.1.tar.gz')
Thanks.
--
Yang Zhang
http://yz.mit.edu/
--
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-disc...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
Share your Pylons best-practices?
Hi all, I've been dabbling in Pylons for about a year now, bringing myself up to speed on an outstanding enabling technology that shows real depth and breadth. An experienced Python programmer, I am quite impressed. The software is mature, and implements a lot of great insight into what it takes to design - and not just hack together - a stable web application. The mental-model is sound. I still find myself struggling, though, with certain fairly basic architectural questions when starting an application in Pylons. I was hoping that some of the more experienced Pylons crew would take a few minutes and maybe help compile some best-practices that will allow others get off the ground more quickly. To get things started, I'll outline a couple of questions that I'm still waffling on. If you'd like to chime in on these OR offer some of the best-practices that you've settled on, I'd really appreciate it. 1) How many Controllers? Pylons supports multiple Controllers. When should you use more than one? How many should you use? One for each of the major entities in your object mode? 2) How to treat templates? The Pylons documentation seems to suggest (to me at least) that the right way to use templates is to dump data - typically strings and other literals - into the template context and simply render the template. We could choose, instead, to use render_def and pass the data as explicitly named parameters to template defs. Which method do people prefer? 3) Segregation of display functions from other processing This is a more general encapsulation question suggested by the previous question. We COULD, if we wanted to, have the controller add ITSELF to the template context. The template, then, would have access to all the functionality that the Controller embodies. Alternatively, we could put just the Controller's methods into the template context. Or we could just pass in literals. Where do folks draw the line? Again, please chime in here with your own best-practices or best- practice questions. I'd love to see a productive discussion of this stuff! Cheers! ~br -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: pylons 1.0 and possible redirect bug ?
On Jul 22, 2:17 am, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote: On Jul 21, 5:56 am, huydo contactm...@gmail.com wrote: Hi, Just trying to do a direct from the __call__ method in my base.py file and this is the following exception which I am getting. redirect(url(controller='redirect', action='index')) File 'c:\\apps\\xbits\\ktrack\\python\\lib\\site-packages\\pylons-1.0- py2.5.egg\\pylons\\controllers\\util.py', line 208 in redirect raise exc(location=url).exception HTTPFound: 302 Found Content-Type: text/html; charset=UTF-8 Content-Length: 0 Location: /redirect/index Adding the following line to my middleware.py file (just after the #CUSTOM MIDDLE HERE) fixed it. app = httpexceptions.make_middleware(app) Is this a bug ? or am I doing something wrong ? I'd say it's more that you're doing something wrong. ;) redirect works by raising an exception (the one you're seeing). Normally, this would be caught by the base WSGIController class (in _inspect_call) and converted into an HTTP response, but because __call__ is a setup function and not part of the action context, the exception isn't caught, presumably by design. In other words, you should only use redirect from within the action context--either in __before__, a particular action method, or __after__. If you really want to redirect from __call__, you can create an instance of HTTPFound and return that from __call__. Hi Wyatt, Thanks for the pointer. It does appear redirecting in __call__ does not work. I have moved all my logic which was in __call__ to __before__ and redirect works in there. It would be nice to be able to return a response in __before__ as well rather then only be allowed to raise an exception. Cheers and thanks again. Huy -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Share your Pylons best-practices?
There was a brief discussion about the controllers in April: http://groups.google.com/group/pylons-discuss/browse_thread/thread/bcdddffc643cca7a/8a976271d6b990b5 I use multiple controllers. My database schema (and form schemas) are in my models directory. My Controllers generally segregate functionality that is 'similar' and corresponds to the http://site.com/controller/action/id RESTful url layout, which is how I think things were intended. I do put in my own route specifically to direct things to a root controller as well. For templates, I populate tmpl_context.variable and use that within the Template. I try to keep as much logic in the controller as possible, but, I have resorted to some logic in templates in the past. Someone once said, MVC is knowing when you need to use logic in the View. Mako (and other template languages) have the capability, but, I try to use it as a last resort. I do value the fact that I can put code in the template if I need to. I have dealt with template languages that have not allowed me to set a variable which results in doing a lot of data manipulation with a non-ORM'ed SQL result prior to sending it to the template. -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: pylons 1.0 and possible redirect bug ?
On Jul 21, 7:13 pm, huydo contactm...@gmail.com wrote: On Jul 22, 2:17 am, Wyatt Baldwin wyatt.lee.bald...@gmail.com wrote: On Jul 21, 5:56 am, huydo contactm...@gmail.com wrote: Hi, Just trying to do a direct from the __call__ method in my base.py file and this is the following exception which I am getting. redirect(url(controller='redirect', action='index')) File 'c:\\apps\\xbits\\ktrack\\python\\lib\\site-packages\\pylons-1.0- py2.5.egg\\pylons\\controllers\\util.py', line 208 in redirect raise exc(location=url).exception HTTPFound: 302 Found Content-Type: text/html; charset=UTF-8 Content-Length: 0 Location: /redirect/index Adding the following line to my middleware.py file (just after the #CUSTOM MIDDLE HERE) fixed it. app = httpexceptions.make_middleware(app) Is this a bug ? or am I doing something wrong ? I'd say it's more that you're doing something wrong. ;) redirect works by raising an exception (the one you're seeing). Normally, this would be caught by the base WSGIController class (in _inspect_call) and converted into an HTTP response, but because __call__ is a setup function and not part of the action context, the exception isn't caught, presumably by design. In other words, you should only use redirect from within the action context--either in __before__, a particular action method, or __after__. If you really want to redirect from __call__, you can create an instance of HTTPFound and return that from __call__. Hi Wyatt, Thanks for the pointer. It does appear redirecting in __call__ does not work. I have moved all my logic which was in __call__ to __before__ and redirect works in there. It would be nice to be able to return a response in __before__ as well rather then only be allowed to raise an exception. It's a bit of a hack and probably not recommended, but you could do this: def __before__(self, ...): response = some response response._exception = True return response But this pretty much what Pylons does for you when you use the redirect function or raise any other subclass of webob.exc.HTTPException in __before__. I think if you are returning default content under some set of conditions that redirecting is the proper thing to do anyway. Or did you have a different use case in mind? -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Share your Pylons best-practices?
On Wed, Jul 21, 2010 at 5:44 PM, BrianTheLion rossa...@hotmail.com wrote:
I was
hoping that some of the more experienced Pylons crew would take a few
minutes and maybe help compile some best-practices that will allow
others get off the ground more quickly.
There aren't really any definitive answers to these. Many of the
design decisions in Pylons or in Pylons tutorials are arbitrary. There
are several roughly equal ways to do something, and the Pylons
developers prefer one way, other frameworks prefer another way, etc.
Many of these alternative designs can be implemented in Pylons, but
they would be unfamiliar to a new Pylons developer who joins the
project, or somebody on IRC you ask a question to.
1) How many Controllers?
Pylons supports multiple Controllers. When should you use more than
one? How many should you use? One for each of the major entities in
your object mode?
It depends how complex the application is. If the site has multiple
sections, each with more than one or two actions, it makes sense to
use a separate controller for each section. And of course, RESTful
resources deserve their own controllers. Miscellaneous onesie and
twosie actions can be put together in a miscellaneous controller; I
use a controller called 'main' for these.
2) How to treat templates?
The Pylons documentation seems to suggest (to me at least) that the
right way to use templates is to dump data - typically strings and
other literals - into the template context and simply render the
template. We could choose, instead, to use render_def and pass the
data as explicitly named parameters to template defs. Which method do
people prefer?
The traditional Pylons way is to assign them to 'c' variables
('tmpl_context' attributes), and access them in the template as
'${c.foo}'. The reason for this is historic. Myghty predated Pylons,
and Myghty had several magic one-letter variables, 'c' being one of
them. It follows a certain MVC pattern, 'c' being a scratchpad for
request-local variables. 'c.' also makes it easy to tell in the
template whether the variable was defined in the template or came from
higher up.
Older Pylons (0.9.6 and earlier) had a render function that took
keyword args for variables. but the official way was to use 'c'. The
keyword args were eliminated in 0.9.7 to confirm to the Python
principle There's Only One Way To Do It.
But it does make a difference between Pylons and TurboGears, with
doesn't normally use 'c'. A TG action returns a dict of variables, and
the @expose decorator applies them to a template. This means you have
to add 'c.' or remove 'c.' when porting templates to/from TG.
You can make a new render function that does what you describe, but
you'd have to write it yourself.
3) Segregation of display functions from other processing
This is a more general encapsulation question suggested by the
previous question. We COULD, if we wanted to, have the controller add
ITSELF to the template context. The template, then, would have access
to all the functionality that the Controller embodies. Alternatively,
we could put just the Controller's methods into the template context.
Or we could just pass in literals. Where do folks draw the line?
This gets into the alternative MVC theories. The Pylons/TG tradition
is that the model knows only about itself, the template knows only
about itself and its context variables, and the controller knows about
both the model and the template. Some developers allow the template to
access the model for trivial lookups (e.g., to expand abbreviations),
but not for the main action data.
Another tradition, which I've seen in Java and wxPython apps, moves
the database out of MVC. The controller instantiates a model and
passes it to the view. The model is a class which contains the data
the view needs, or what Pylons calls 'tmpl_context'. But in this other
MVC it's a class designed specifically for this view, not a generic
container. There's also a scratchpad, a set of request-local data
which is available to all the utility methods and the view.
And of course, Django calls the controller the view, and the framework
the controller.
What you're talking about is something different still, the view
knowing about the controller. Although that could be reconciled with
the Java MVC if we equate the controller with the model.
See how confusing it gets? Who's on first? --No, What's on first.
--No, What's on second; Who's on first.
http://www.phoenix5.org/humor/WhoOnFirst.html
What you seem to be getting at is, there's no place for view logic in
Pylons except in the template. And Python code in the template is hard
to debug unless it's short and simple. So people put it in the
controller instead, even if it's view logic. This could be alleviated
if there were a view object for every view, and the view object
managed the template. You could do this with Pylons, but you'd have to
write it yourself. I don't know of anyone who has written an
application this
