Am 02.01.19 um 09:09 schrieb Mike Orr: > On Wed, Dec 26, 2018 at 11:18 PM Gerhard Schmidt <[email protected]> wrote: >> >> Hi Mike, >> >> Am Mittwoch, 26. Dezember 2018 19:04:37 UTC+1 schrieb Mike Orr: >>> >>> On Wed, Dec 26, 2018 at 12:28 AM Gerhard Schmidt <[email protected]> wrote: >>>> is it possible to store additional information in the view config. >>>> >>>> Background is that i would like to add more information the the view >>>> processed later by the layout tho generate the navigation of a page >>>> automatically. >>>> >>>> I would like to store the title of a page (for the navigation link) and >>>> the navigation type. >>>> >>>> The simplest solution would be to copy any unknown keyword arguments >>>> given to view_config to the Introspectable or be able to add custom >>>> keywords to be copied via config statement like adding custom predicates >>>> to the view config. >>> >>> I don't know whether you can store additional args this way, but it >>> sounds like the wrong structure for this kind of information. A page >>> title is page specific, not view specific, and parent titles (for >>> navigation links or previous/next links) sound like resource >>> information. Is this a pure URL Dispatch application with no resource >>> tree that could hold this information? I generally put my page title >>> in a Mako template function or I set it during the view's action. If >>> you have class-based views, you could store the navigation tree in a >>> view class attribute, and then use the runtime view's name to figure >>> out the current position in the tree. You may not need a multilevel >>> tree to navigate just one level up and one level across, with a >>> well-known "Home" link above that. >> >> >> first, why didn't i get you mail via mailinglist? >> >> It's a traversal application. so views are bound to context rather than urls. >> >> Right now i have a action_config decorator that adds a view with the given >> information and store the additional information in a second Introspectable >> in the registry. >> >> Would be much more convenient to store this information directly at the view. >> >> The pagetitle in my application is quite view specific and the navigation I >> am implementing is not only the site navigation (the site navigation is >> quite trivial) but the navigation within the object which can be quite >> complex. >> >> Storing this information in the registry works quite well for me. And being >> able to do that directly in the view Introspectable would cut some >> complexity. >> >> But my use case must not be the only one. So I think the question is not if >> the view Introspectable is the right place to store a pagetitle. The >> question is, should there be a way to store more information in the View >> Introspectable and how difficult is this to be implemented. >> >> Regards >> Estartu > > I had an idea about this. When you want to associate data with a > callable you can use a partial function. For instance: > > # views.py > def my_view(title, request): > .... > > # __init__.py > import functools > title = "My Title" > view1 = functools.partial(my_view, title) > config.add_view(view1, ...) > > Or you could write a wrapper for view_config that does this. > > I've never needed additional view data like this because my titles are > in my templates or in my view code. (I have a Mako site template with > a 'page_title' function which I override in the individual templates.) > But if you can't specify the title in either of those places or in the > context, then I'd use a partial function like this. > > Outside Pyramid I'd use a callable class: > > class MyClass: > def __init__(self, title): > self.title = title > def __call__(self, request): > # Use self.title. > > But that wouldn't work as a view class because Pyramid makes certain > assumptions about view classes that are incompatible with this. You > might be able to configure an instance of it: > > config.add_view(MyClass("My Title"), ...) > > But I haven't tried it and I don't know whether Pyramid would treat it > like a function.
Hi, I'm not trying to hack this (I'm already done the hack). I proposing to add a clean documented way to do something like that. Hacking around the system always introduce the possibility of future incompatibility. I'm developing systems that are long living and under my maintenance for the whole time. So I try to stay rather close to the system to minimize update issues. The Introspectable is already a dict like object. So adding any additional information would not be a technical problem. There is right now code in place that checks if there are arguments that are unknown before adding everything to the Introspectable. There is a way to register arguments to store information for tween to work with, but my code is no tween but just rendering. Just removing the checking code would add this feature. But I really like the checking. So a way to just add to the list of known arguments would do. I try to get some code done in the near future. Regards Estartu -- ---------------------------------------------------------------------------- Gerhard Schmidt | http://www.augusta.de/~estartu/ | Fischbachweg 3 | | PGP Public Key 86856 Hiltenfingen | JabberID: [email protected] | auf Anfrage/ Tel: 08232 77 36 4 | | on request Fax: 08232 77 36 3 | | -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/3934dd3a-a5c7-aa7a-acfa-8e06f4679963%40augusta.de. For more options, visit https://groups.google.com/d/optout.
<<attachment: estartu.vcf>>
