event suscriber, request property or session

[Antonio Beamud Montero]

Hi all:
I want to have the inbox messages number associated with a user always
available.
What's the best way to do this?. As I can read in documentation, I can
accomplish this with:

- adding a property to the request with 'set_request_property', like:

myconf.set_request_property(calculate_user_inbox, 'inbox')

- Using an event suscriber:

myconf.add_subscriber('myapp.calculate_user_inbox_suscriber',
'pyramid.events.NewRequest')

- Using the beaker session.

What's the pros and the cons?

Greetings.

[Chris McDonough]

You haven't described what's wrong with just calling
"calculate_user_inbox" from view code without involving any of the above
things. I doubt there can be any reasonable discussion of pros and cons
without understanding why you're trying to involve framework machinery
in the first place.

- C

[Jonathan Vanasco]

> - adding a property to the request with 'set_request_property', like:
>       myconf.set_request_property(calculate_user_inbox, 'inbox')
>
> - Using an event suscriber:
>      myconf.add_subscriber('myapp.calculate_user_inbox_suscriber',
>                            'pyramid.events.NewRequest')
>
> - Using the beaker session.

I would probably drop it in the session variable , or add an object to
your request property that you stash multiple values in.

- The request object tends to have a lot of attributes on it that are
critical to Pyramid. Being a bit aggressive about safety and
collisions, I personally prefer to create an private namespace on it,
and then stash everything in there. So instead of request.inbox , I
would prefer request.antonios_app.inbox -- and then have that nice
private space for anything else my app needs.

- myconf.set_request_property and myconf.add_subscriber are
essentially two execution hooks you can use to handle the logic/
calculation. IIRC , you could use the add_subscriber to manipulate
the session object ( you can definitely use it to manipulate the
request object ).

- if you're using class-based Pyramid views, you could also have a
base class do the work on __init__ (
http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/views.html?awesome#defining-a-view-callable-as-a-class
)


Personally, I would probably opt for the an event_subscriber or
__init__ to manipulate the beaker session -- and only because I'd want
to store this information in the session, along with a timestamp, and
have it cached for 5-10 seconds. In a dev environment, all of your
files ( static included ) will be served by Pyramid, so calculating
this nonstop would make testing a bit annoying. In production, you'll
probably run into this being a bottleneck... and offering some ability
to cache could offset needing to scale hardware a bit.

[Antonio Beamud Montero]

El 02/07/12 17:17, Chris McDonough escribi�:

The inbox number is shown in the header of the site. This header is
defined in a template which is inherited by the other templates.
I'm using pyramid_handlers to group the views. Then, to make this method
accesible to the header template, I need to pass in all view methods,
and this is ugly.
Then if I can access as a request property (via suscriber or property),
like

<a href='...'>Inbox (${request.inbox_number})</a)

can be the cleanest way...
Thanks and pardon my ignorance.

[Michael Merickel]

Well when you say "always available", are you *sure*? Do you want it
available when serving static resources? If you create a request
property then it is lazily calculated when you actually do request it
and with reify=True it will cache the result for the request duration.
NewRequest subscribers are invoked for *every* request after it has
gotten through middleware and tweens, but before Pyramid's router
takes over.

Sessions are for tracking state across requests, so you could store
the number in the session when they log in. I am of the opinion that
sessions are overused and almost anything stored in there is an
indicator that your data model is incomplete.

There's umpteen ways to store state in Pyramid, starting at global
solutions and drilling down into local solutions. It's really
dependent on your requirements to determine how to do things within
Pyramid.

Note that if you just want something to appear in a template, the
BeforeRender event is where you should be looking to implement that
behavior. It's a good way to handle passing state to a base 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-...@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.
>