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.
@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. 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.
