Task plugin for 'admin/workbench'

Essentially we've moved all code specific to these two components (workbench_content and workbench_create) and we've fully encapsulated everything those items need in order to be called in a standalone manner by context admin. This means that if I wanted to generate my own custom "workbench" and I wanted to utilize these portions of what workbench module does, I could reuse them from the UI w/o needing to dig into code.

We've then provided our own simple rendering utility for context_admin plugins. This could probably be updated to work for ctools content_type plugins as well, at which point I would advocate moving away from the views page_display and having hardcoded menu items for your views where the view that is used is a content_pane display. This makes all your views reusable for anyone wanting to mash them up in their own panels. I guess that would add a "views_content" dependency so perhaps you're -- to that... hmmm well, I think you probably get where I'm going at this point. The bottom line is you have a lot of really awesome stuff here that with a little work could be very reusable for people outside of workbench. I'd personally like to see workbench NOT deploy menu items for the sake of sanity, but I realize I will probably not be able to convince anyone of that in the near term, so the complete goal here is to provide reusable components.

@stevector

Exactly, if a view doesn't take a path, and instead relies upon page_manager to place it, page_manager allows for additional variants to be added to a page. As such you can clone the view in question, change as desired, and set up a variant that displays your view instead of the default. Typically this is done with selection rules on the variant and once you understand page_manager is quite trivial to both setup and export (since you're exporting JUST the variant and not the entire page's settings). The best way to do this is to actually provide a "task" plugin for the path in question. I intend on demoing that eventually but hadn't really tried to make it that far yet.

Eclipse

Stevector,

So... there are various things at play here, so I'll try to be as concise as possible w/o assuming you know ctools/page_manager too much.

There's an obvious hesitancy to add new dependencies to workbench, I respect this, but the degree to which you can embrace available tools w/o increasing your install overhead is something you'll have to balance I will just try to make the arguments for new dependencies. Specifically 2, which you already have available because ctools is present. Page_manager and Views_content. I WANT to see a page_manager dependency, but I don't view this as absolutely necessary. I think you NEED a views_content dependency for the availability of additional views display types (view panes specifically). This is at first sort of a "wtf?" because view panes display in panels, but we can write a custom handler for displaying these at our own custom paths (see how I did this with context_admin plugins w/o the need for a context_admin dependency in the commits I've sited here). This means people who install panels get the benefit of your views in a panels native format w/o you needing a panels/page_manager dependency.

That being said, I mentioned moving to explicit paths instead of views doing that work. This allows us to write a task plugin for page_manager. When page_manager is enabled, the task tells page_manager how to override your custom paths, this does not make you dependent, just gives your users additional flexibility for workbench defined paths. i.e. if they want to change the output of a given path under certain conditions, they'd have that ability. (say cloning one of your base views, changing it and displaying that instead of your packaged view for some particular role). These sorts of settings would also be exportable so they could "featurize" workbench alterations w/o needing to hack workbench at all.

Bottom line, the setup work your end users do is no greater than it currently is (because you've custom defined all your menu paths and what appears on them), there is one additional module dependency (views_content), and one suggestion (page_manager) both of which are in ctools, so... and you allow your users to leverage the whole ctools stack for your tools if they so desire, and if not, they remain blissfully ignorant.

In so far as what I've written, it's definitely a proof-of-concept in that, we'll want to expand what the basic page callback I've written thus far can do so that it CAN leverage a ctools context stack (in case you start passing user contexts, or node contexts, or something else in the future). As it is, it's probably sufficient for your current needs, but the leg work to get it complete is probably not that extensive. I think I have an example of code that is closer to "complete" sitting around somewhere. I just need to go find it.

Hopefully this answers your questions?

Eclipse

Stevector:

Points 1 & 2: YES, you have hit the nail on the head completely. Everything you said there was correct.

Point 3: We would have to discuss what views fallback mechanism is for such situations, but I doubt it will be "graceful". ;-) You already have ctools dependency, you're just adding an additional dependency you already have the code base for. I understand that there is some reason you all are gun shy about this, all I can say is "try it see". I think the payoffs are worth whatever perceived downsides there are.

Concerning your "menu_alter" statements, again "YES" this is all true, the only way around that is to utilize a page_manager dependency, forgo the task plugins and utilize page exports. These are able to be turned on/off from the UI. This is actually simpler than going to the trouble of writing task plugins for all your ongoing administrative space needs, but again we're back to the dependency thing. The other point here is that you could end up with panels or context_admin or both as potential dependencies if you went this route. Obviously I have no problems with that, but you all may. Many of us working in this space do full install profiles and make files for every client, so these sorts of dependency trees are trivial and largely "solved" for us. I understand it may not be that way for you all.

With your last post, you've demonstrated that you understand the problem space well, and what I believe to be the potential solutions. I was hoping to collaborate within workbench to solve what I see as an additional, largely unidentified problem space within drupal, and that's this idea I have of menu clustering. i.e. all your content is actually at admin/workbench/... Such a thing could be potentially tokenized and the option of deploying it at /warroom becomes a simple matter of setting a single variable somewhere and telling all the related pages to deploy. Obviously no solution exists here yet, I'm hoping page_manager + some custom code on my part can eventually make this a reality. Workbench was the medium I was hoping to play with that idea in. Obviously that may not be practical directly concerning workbench, but you all have a lot of great stuff sitting here, and deconstructing it to a point that I/we can prove this is a good idea is very appealing to me. I have other code I could use for this purpose, but in that case I have all the same assumptions I always do, and I need to find out of these ideas map against other solutions.

Hopefully that clarifies my interests, and shows where the real obtainable benefits are, and what I hope solutions for tomorrow might look like.

Eclipse

Happy to have helped prod it this far. I'll try to review this at some point and add any thoughts I might have.

Eclipse