I’d look into defining the views the same place you define the routes, since 
you’ll need to generate routes with this same “foo” pattern.  Something like:

def includeme(config):
    for suffix, url, renderer in generate_foo_urls(“/a/“):
        route_name = f”a:{suffix}”
        config.add_route(route_name, url)
        config.add_view(“foo.bar.view”, route_name=route_name, 
renderer=renderer)

Or flip that on its head:

def generate_foo_views(config, view, url_prefix):
    for suffix in [“a”, “a.json”, “b”, “b.json”]:
        route_name = f”a:{suffix}”
        config.add_route(route_name, url_prefix + suffix)
        config.add_view(view, route_name=route_name, renderer=‘json’ if 
suffix.endswith(‘json’) else ‘1’)

Depending on the details of `route_pattern=“foo”` these samples might not be 
exactly applicable, but I think some variation of them will work for you.

>  thought I could pull this off with a custom decorator that creates the 
> view_configs, but the more I look into how view_config works, I don't think I 
> can pull this off in a non-fragile way.


I don’t see any problem with a custom decorator.  view_config just calls 
config.add_view via venusian, it should be straightforward enough to make a new 
decorator that calls config.add_view multiple times.

— Theron



> On Mar 20, 2025, at 10:48 AM, Jonathan Vanasco <[email protected]> wrote:
> 
> In a certain project, I have many views that have multiple @view_configs that 
> follow a few patterns; roughly something like this:
> 
>     @view_config(route_name="a", renderer="1")
>     @view_config(route_name="a:a", renderer="1")
>     @view_config(route_name="a:a.json", renderer="json")
>     @view_config(route_name="a:b", renderer="1")
>     @view_config(route_name="a:b.json", renderer="json")
>     def view(request):
>         pass
> 
> I'd like to simplify this with something like
> 
>     @view_config(route_name="a", renderer="1", route_pattern="foo")
>     def view(request):
>         pass
> 
> Then, based on "foo", programmatically generate what the other view_configs 
> would have been and register them into Pyramid.
> 
> I got inspired for this idea with view derivers, and thought I could pull 
> this off with a custom decorator that creates the view_configs, but the more 
> I look into how view_config works, I don't think I can pull this off in a 
> non-fragile way.
> 
> Has anyone tried to do something like this before and can offer tips?
> 
> -- 
> 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] 
> <mailto:[email protected]>.
> To view this discussion visit 
> https://groups.google.com/d/msgid/pylons-discuss/6fc32701-b9aa-4542-bddf-c504d9b5ef48n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/pylons-discuss/6fc32701-b9aa-4542-bddf-c504d9b5ef48n%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
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 view this discussion visit 
https://groups.google.com/d/msgid/pylons-discuss/F14D4C98-F653-4ECB-99CA-DE96EEE8CFE6%40luhn.com.

Reply via email to