Re: is it safe to store data on handlers/views in "self", or should it be "self.request" ?
FWIW, I started working on this approach a few weeks ago, and have 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. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@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: is it safe to store data on handlers/views in "self", or should it be "self.request" ?
Re the original question, storing state on your view as a class is fine, because the class is always instantiated and called once per request, with no shared state ( unless you explicitly make it shared through class attributes ). This has the very happy side effect of making testing a lot easier because if you store the intermediate stages of your view logic as attributes on the view object, you can interrogate the view itself at the end of your tests to make sure it did the right thing. Iain On Fri, Feb 3, 2012 at 8:12 PM, Mike Orr wrote: > On Fri, Feb 3, 2012 at 8:03 PM, Blaise Laflamme > wrote: > > 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 > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to pylons-discuss@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. > > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@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: is it safe to store data on handlers/views in "self", or should it be "self.request" ?
On Fri, Feb 3, 2012 at 8:03 PM, Blaise Laflamme wrote: > 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 -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@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: is it safe to store data on handlers/views in "self", or should it be "self.request" ?
same opinion than Chris -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To view this discussion on the web visit https://groups.google.com/d/msg/pylons-discuss/-/adcXZaPK-6UJ. To post to this group, send email to pylons-discuss@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: is it safe to store data on handlers/views in "self", or should it be "self.request" ?
On Fri, 2012-02-03 at 19:47 -0800, Jonathan Vanasco wrote: > could we rename pyramid_handlers to pyramid_controllers ? its the > pylons appropriate name for them, and would probably solve a handful > of issues. 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 -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@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: is it safe to store data on handlers/views in "self", or should it be "self.request" ?
could we rename pyramid_handlers to pyramid_controllers ? its the pylons appropriate name for them, and would probably solve a handful of issues. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@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: is it safe to store data on handlers/views in "self", or should it be "self.request" ?
On Fri, 2012-02-03 at 14:25 -0800, Mike Orr wrote: > On Fri, Feb 3, 2012 at 12:18 PM, Chris McDonough wrote: > > On Fri, 2012-02-03 at 12:12 -0800, Jonathan Vanasco wrote: > >> great. that looks good. > >> > >> 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 > > > > Handlers are views too. So this works there as well, if you'd rather > > continue using those. > > 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. 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 > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@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: is it safe to store data on handlers/views in "self", or should it be "self.request" ?
I set up my views using classes (the actual views are methods) that
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 writes:
> On Fri, Feb 3, 2012 at 10:32 AM, Jonathan Vanasco
> 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
>
>
> ...
>
> # Index template
> Welcome to ${project}.
>
> ===
>
>
>> 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
--
Parnell "ixmatus" Springmeyer (http://ixmat.us)
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@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: is it safe to store data on handlers/views in "self", or should it be "self.request" ?
"class-based view" is the appropriate term here. I think that "handler" should only really be used in the context of pyramid_handlers. On Fri, Feb 3, 2012 at 4:25 PM, Mike Orr wrote: > On Fri, Feb 3, 2012 at 12:18 PM, Chris McDonough wrote: > > On Fri, 2012-02-03 at 12:12 -0800, Jonathan Vanasco wrote: > >> great. that looks good. > >> > >> 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 > > > > Handlers are views too. So this works there as well, if you'd rather > > continue using those. > > 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 > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to pylons-discuss@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. > > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@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: is it safe to store data on handlers/views in "self", or should it be "self.request" ?
On Fri, Feb 3, 2012 at 12:18 PM, Chris McDonough wrote: > On Fri, 2012-02-03 at 12:12 -0800, Jonathan Vanasco wrote: >> great. that looks good. >> >> 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 > > Handlers are views too. So this works there as well, if you'd rather > continue using those. 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 -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@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: is it safe to store data on handlers/views in "self", or should it be "self.request" ?
On Fri, 2012-02-03 at 12:12 -0800, Jonathan Vanasco wrote: > great. that looks good. > > 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 Handlers are views too. So this works there as well, if you'd rather continue using those. - C -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@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: is it safe to store data on handlers/views in "self", or should it be "self.request" ?
great. that looks good. 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 -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@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: is it safe to store data on handlers/views in "self", or should it be "self.request" ?
On Fri, Feb 3, 2012 at 10:32 AM, Jonathan Vanasco 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
...
# Index template
Welcome to ${project}.
===
> 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
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@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.
