Is this ticket maybe a good opportunity to handle view options differently? Instead of passing args in all the views, they could be passed as formatter attributes (one or more).

Re the comment above, I think this is definitely something we need to explore. More on that soon.

Re the proposal, we were definitely working on some of the same challenges here and in the showhide branch.

Some assorted comments:

1. As things stand, none of the above methods could do much of anything without the args hash. (that could change)

2. There is a Wagn 1.13 ticket about changing the :show view from a view to a standard method (def show), which is the controller's entry point. I'm not sure now I feel so committed to that approach, but it's worth noting because the method names would conflict.

3. the first two should probably have bangs

4. BUT, I don't really like the idea of altering the inclusion setting. The new API obviates that by providing a mechanism to override it without altering it.

5. The new #show_view? method is awfully close to #show? above.

6. #default? above is basically nonsensical, since the true default is determined not by the view or even the args but by the optional_render method call. I think you said as much above, so I'm not sure what the idea is.

I guess my ultimate question is: with the new api, is there a need for any of the above?

I'm much more excited about the prospect you bring about above, though I think I would suggest something a bit less extreme.

I think the *inclusion* args should no longer be args. But rather than attributes (plural) of the Format instance per se, they should be attributes of an inclusion object (or Nest, if you like that new terminology), and that object itself is an attribute of the Format. so @format.nest would give you your current Nest object, which itself would contain all the standard nest attributes. the nice thing about this grouping is that this means we have just one object to reset with each subformat rather than a whole slew of them. This has to be a major consideration whenever adding attributes to a Format object -- subformats inherit shit, and we have to make sure it's intentional.

Regardless of how we represent it, I do think that when possible we should avoid editing nest configurations. Those are wagneer configurations and should generally be preserved, even when overridden.

I also think that there is still a strong case for args, because often a given view can actually be called multiple times by the same Format object, and that is valuable. But there's too much passing stuff around, and I generally think args stuff can get pretty ugly. so I think we're generally on the same page here.

re your question above, yes _optional_render is to optional_render and _render is to render.

That said, I think we should get rid of both the underscore variants soon. We're only skipping permission to optimize, but this is a poor way to handle that. In general, read permissions need to be checked once per card (which often means once per format object), and we're using the underscore trick to make that happen. Instead it should be happening at the ok_view level. In fact, I think it kind of is already.

By the way, it's completely correct that the optional_render method call should determine the default state. It depends on the context of the view that calls it. menus, for example, default to hide on titled view and default to show on open view. I'm not saying I love that particular design, but it's important that the api support patterns like that.