On Fri, 2012-01-06 at 07:45 -0800, Ahmed wrote: > I've read more into the documentation of view_name. Although I've > discovered that I can set a view name in config.add_view(), I found > out it does not work in a dispatch mode. (gives a resource not found > error) It seems the whole view_name thing is entrenched in traversal > mode. (which I haven't used) and is not just a view name string that > one can use to look up in the config afterwards.
Yes, view_name is a traversal-only thing. > > @Chris, > My app design (almost a CRUD like admin app) decouples the page > rendering from the view and the sqlalchemy model. So what each view > does is mainly load the resource (the sqlalchemy model), do some > optional action to it, then finally pass the request + the model + the > view action (which I intended to be the view name, for example, > create, delete, update etc.) to a page renderer which then passes > these arguments to go through different parts of the page (I call them > blocks a la drupal) and decide what to render based on these arguments > + any extra arguments passed. > > For example, the #main div contains the form, which gets decided > according to the passed action argument create/edit/delete etc and > loads the passed model into it. > > This design was heavily inspired by drupal (I feel I am trying to > recode drupal in python), and I put it that way to decrease the amount > of code I have to type if I wanted to extend the app or tweak > features. This wouldn't of course have been possible without the > flexibility of pyramid. > > The use case for which I actually needed this feature was: to render a > title/header for each page. In my case this depends on the view action > itself. For example, if it was 'create', the I want it to be Create > Employee. When it is 'view' I want it to set it to the Employee name > and id. If it was 'delete' I want it as "Are you sure?". > > Now all this code is clumped in one place. (in the #header block in > the page) > But see, this is bad for extensibility. What happens if I decided > later on, in a derived app, to set the page title to name of the > Employee, but tweak it for a Student, to be his name plus his degree!! > Dividing this code in many but relevant places will be a lot better. > (each view holds its code for setting the page title, e.g. which can > then be overridable etc.) so what I need is to be able, from the #page- > title block to gain a pointer back to the view itself and call some > view code. > > And now, since it looks that view_name is a pure traversal thing, I am > left with two options, which are after all are equally good: > 1) I would either pass a reference of the view instance to the page > renderer instead of just passing the view 'action'. > 2) I would ditch the reference to the view during the view > initialization __init__. (I prefer this one) and leave rest of my code > as is. For what it's worth, the variable "view" in any template is always the current view object. - C > > > Ahmed > > > On Jan 6, 11:30 pm, Chris Rossi <[email protected]> wrote: > > On Fri, Jan 6, 2012 at 5:42 AM, Ahmed <[email protected]> wrote: > > > Hi all, > > > > > just noticed that this post sunk down and was wondering if there is an > > > answer to that question .. or perhaps whether I can request it as a > > > new feature an upcoming version of Pyramid (Chris?)? (registering a > > > view_matched like we have a route_matched in a dispatch context). > > > > What is the use case for this? You generally know the view that > > matched, because it gets called. > > > > Chris > -- 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.
