On Fri, Feb 3, 2012 at 10:32 AM, Jonathan Vanasco <[email protected]> wrote:
> under pylons I had a lot of code that did misc prep work for certain
> methods in the request.
>
> because every view was an instance, it was pretty safe to just store
> stuff in the instance of the 'handler' class, and i didn't need to
> store it into the request object.
>
> i'm not sure how pyramid is set up. it seems that every view creates
> a new instance of the handler class as well -- but i wanted to be
> sure.
Chris has recommended storing stuff in the view, and the
Pyramid/Pylons guide I'm working on will document it as an alternative
to t'mpl_context'.
===
class MyViewClass(object):
def __init__(self, request):
self.request = request
self.variable_for_site_template = "value"
# The above variable is used only in HTML rendering; it's not
part of the view's return dict for JSON, etc.
@view_config(route_name="...", renderer="...")
def index(self):
return {"project": "Hello"}
# Site template
<head>
<meta name="keywords" content="${view.variable_for_site_template}" />
...
# Index template
<p>Welcome to ${project}.</p>
</head>
===
> def _shared_setup_a():
> "used by one or more methods , but not all"
> self.db = newdb()
> self.gaq= new_google_analaytics()
This looks reasonable. It's essentially what I do in Pylons, and what
I'd do in Pyramid. I like this approach for processing common input
such as record IDs: the method validates the parameter type (numeric),
fetches the database record, and attaches it to 'self', or aborts the
request if the record doesn't exist.
--
Mike Orr <[email protected]>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
