I already set up some template helpers on before render, I could add user there but having it as a request attribute makes it available in all views too.
I'm not using views as classes but defs, I'd prefer not rewriting them all as classes I'm reading Michael mail again and I assume one more time I was wrong thinking the lifetime of a request expires when the page is rendered and delivered and my request.user instance with it. Do you confirm I was wrong? Any documentation to suggest to better understand how it works? Thanks for your support neurino On Mon, Oct 17, 2011 at 10:20 PM, Parnell Springmeyer <[email protected]>wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Pyramid has an awesome event system - you could easily setup an observer > for any event after a request but before rendering that can query the DB > and provide the user object. > > Or you can go the base class view setup, I make all of my views classes > that extend a base view class - the base view, on every request, gets > the user's id from the session and provides a user object "self.user" > that all extending classes have access to... You could even put it in a > context object if you wanted. > > Michael said it right, re-read that email. > > neurino <[email protected]> writes: > > > What I guessed is my user attribute could be queried *once* *each time* a > > page is _requested_. > > > > What I find is this does not happen as reloading a page — which happens > to > > be returned by a different thread than the one that operated on the > > collection — user attribute is steady at a precedent state and *not > > retrieved again* upon new request. > > > > Maybe I misunderstood the recipe but _why make a user available that way_ > > also for *any* attribute that can be edited? > > As far as I know usually only userid is immutable and it's already > > available. > > Every other property could lead to my same problem: user changes email > then > > he finds it unchanged in next profile page... > > > > So, is there an option for getting a new fresh user queried on each _page > > request_ (honestly I thought it was the same as _request_ but I see it's > > not)? > > > > @Parnell: I *do need* full user data in each page as I need to show user > > items in sidebar. Choices. > > > > Thank you for your support > > neurino > > > > > > On Mon, Oct 17, 2011 at 7:24 PM, Michael Merickel <[email protected] > >wrote: > > > >> Okay, I can't tell if you are misunderstanding that cookbook recipe, or > if > >> you made the decision independent of that to store the user object in > your > >> *session*. That is not what the recipe is advocating. It advocates a > >> mechanism to query the user the first time you access that property of > the > >> request object and cache the result in memory for the lifetime of that > >> request. > >> > >> Now if you decided that instead of querying the user from a database you > >> would get it from a session then that's fine, but you need to understand > >> that you are serializing a sqlalchemy object into a cookie. Thus when > you go > >> back to load that object from the cookie, you need to reconnect it with > the > >> database to make sure that it didn't change. This is done via the > >> DBSession.refresh(). The point here is that either way is valid, but you > >> *will* need to talk to the database once per-request if you want to use > that > >> object with SQLAlchemy. > >> > >> Another option is to only serialize the properties of the user that you > >> care about, then you can use those directly without having to talk to > the > >> database. Then you're making the assumption that those properties didn't > >> change in the background. > >> > >> > >> -- > >> > >> Michael > >> > >> -- > >> 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. > >> > > - -- > Parnell "ixmatus" Springmeyer (http://ixmat.us) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBAgAGBQJOnI34AAoJEPvtlbpI1POLXuoIAJ2QojCcV4VDh0Dm0WAZoavk > 2owq3lQPZ4LUA6Ucsznv9opmHRYWJqQ4vbrEZ74H3+MYtLnWMAdxFB3q2Bq5NpK3 > q5vtjUlmBJN3TpXjqryGJ5SFfk3oUS556GyHBYiYVRsLnOgVLgsj0uuv4zqKTapF > HzpymB9AYw/FAA0p7mHMi5vtaOiHGgVAXilLtlgSyM1z9Ne+rmCCArQ4PMGJLVmW > u5+qx46iJMna0sLXF/PxB35UJZfAAYzQa5VScaqbozxxF422lHddB8sXRCCfTbbB > iSuzUWoSsxf5+ellOTnPzqKNpUo8PqwDE1unkJ86zl8nrhbO5giWkHkSblRgvkw= > =QM6x > -----END PGP SIGNATURE----- > > -- > 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. > > -- 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.
