Handling Show-Hide Options

Idea

 

When I want to hide or show an optional render in a module, I want an API to help handle the :show and :hide options passed from the Wagneering level.

 

Add some helper methods to the base format class:
  • hide(:viewname) Removes :viewname from show, adds it to args[:hide]
  • show(:viewname) Removes from hide, adds to show
  • hide?(:viewname) Is view present in args[:hide]
  • show?(:viewname) Is view present in args[:show]
  • default?(:viewname) Returns :hide or :show
The semantics of this now is a bit odd, so I think it could use some work. The default hide/show is only present at the final call to optional_render, and _optional_render needs to be considered (relates to view permissions? args[:allowed]=true.

 

 

 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).

--Gerry Gleason.....2014-02-01 15:23:08 +0000

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?

--Ethan McCutchen.....2014-02-02 03:27:24 +0000

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.

--Ethan McCutchen.....2014-02-02 03:37:46 +0000

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.

--Ethan McCutchen.....2014-02-02 03:41:07 +0000

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.

--Ethan McCutchen.....2014-02-02 03:52:12 +0000

+relevant user stories