extending view_config for generative/patterned implementations ?

[Jonathan Vanasco]

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?

[Theron Luhn]

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

--
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 pylons-discus...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pylons-discuss/6fc32701-b9aa-4542-bddf-c504d9b5ef48n%40googlegroups.com.

[Jonathan Vanasco]

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.