Thanks for the insight! > 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.
Unfortunately, that probably won't be an option, and I'll have to go with the decorator model. At least for now. I feel more comfortable pursuing that with your explantation though! I already handle generating most of these routes programmatically with this package I wrote: https://github.com/jvanasco/pyramid_route_7 I'd actually like to extend that package to support automating the configs for the json & paginated views, but I don't want to require defining it a special way OR couple it too tightly, as an implementation might use view derivers or other features. that's why i wanted to try a decorator approach. On Thursday, March 20, 2025 at 2:52:20 PM UTC-4 Theron Luhn wrote: > 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]. > 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/53b25aa7-4ebe-4e4c-8117-9d87be706ac0n%40googlegroups.com.
