is it safe to store data on handlers/views in "self", or should it be "self.request" ?
Jonathan Vanasco
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.
the paradigms i used sort of look like the following, where i have a
'setup' helper and a multi-method form submission process:
---
def _shared_setup_a():
"used by one or more methods , but not all"
self.db = newdb()
self.gaq= new_google_analaytics()
def login(self):
self._shared_setup_a()
self._login_form= Form()
if submit:
return self._login_submit()
return self._login_print()
def _login_print(self):
render( template, self._login_form )
def _login_validate(self):
if not validate(self._login_form, self.request):
return self._login_print()
redirect( success page )
Mike Orr
> 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 <slugg...@gmail.com>
Jonathan Vanasco
I need to read up more on views vs handlers.
since i use "render_to_response" for most things, I should have an
easy transition
Chris McDonough
Handlers are views too. So this works there as well, if you'd rather
continue using those.
- C
Mike Orr
Chris, Blaise, something to think about for the documentation:
People are getting the idea that handlers are some big separate thing;
i.e., more than they are. I think this is due to how pyramid_handlers
was originally marketed. Part of it I think was an expectation that
ex-Pylons developers wouldn't accept the standard Pyramid API, whereas
actual experience has shown that they're more accepting of it than we
thought.
So in my Pyramid/Pylons guide (and in the Akhet manual) I've tried to
emphasize that a handler is just another name for a view class (i.e.,
a class containing view methods). What pyramid_handlers really gives
you is config.add_handler() and @action. It doesn't give you a base
class: that's an Akhet invention (to parallel Pylons' Base
controller). So I think that where the docs talk about view classes,
they should mention that handler is a common term for a view class,
but it means nothing more than that, and that pyramid_handlers is just
one way of managing them.
--
Mike Orr <slugg...@gmail.com>
Michael Merickel
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Parnell Springmeyer
extend a base class. In the base class I set up globally accessed
variables to self so that all classes extending that base class have
access to them - it's more or less for convenience.
I also use the Pylon-esque context object pattern to make a globally
accessible "c.attrib" object available in my templates.
I also use this, mostly for the session's user object which I cache into
redis.
Mike Orr <slugg...@gmail.com> writes:
--
Parnell "ixmatus" Springmeyer (http://ixmat.us)
Chris McDonough
I'd hope it'd be enough to put somewhere in the handlers docs that
handlers are just special class-based views. I'm not apt to introduce
the term "handlers" into the main Pyramid docs to describe class-based
views, because then we don't have a name for the bundle of logic that we
currently call handlers.
- C
>
> --
> Mike Orr <slugg...@gmail.com>
>
Jonathan Vanasco
pylons appropriate name for them, and would probably solve a handful
of issues.
Chris McDonough
Ben explicitly didn't want them to be called controllers for fear of
people getting them confused with Pylons controllers, which work
slightly differently, FWIW.
- C
Blaise Laflamme
Mike Orr
> same opinion than Chris
Renaming pyramid_handlers would raise backward compatibility issues,
and there's already a proliferation of things being renamed and
retired.
I'm just suggesting a sentence in passing, "Class-based views are
sometimes called 'handlers'", so that users know what that term means
and won't misunderstand it.
--
Mike Orr <slugg...@gmail.com>
Iain Duncan
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
Jonathan Vanasco
been loving it.
I attach two Pylons-style Attribute-Safe objects onto the request at
init :
request.app_meta
request.workspace
app_meta contains stuff like "is the user logged in?" , timestamp /
datetimes for the request, links to packages that store 'constants',
etc. All that is generated on init.
workspace is where i progressively store request specific data that
the application logic works on, like SqlAlchemy objects or cached
dicts. unlike storing this onto the view class, it becomes available
anywhere i have a request object.
I found this works ridiculously well.