For the 6--2 branch, I plan to open up the way that this system works to select nodes to distribute.
The way this module works boils down to this:
- on the Distributor there is a means of marking nodes, and a View that shows some of these nodes depending on arguments
- on the Retriever, you specify the basic connection details (server, account details, key, and view name). The rest (the next two tabs on the settings page) is just a helpful UI that lets you select which arguments to pass to the view (it's this part of the module's UI and architecture that I found confusing at first!)
That means that anything that Views can filter on with an argument is suitable as a means to mark nodes.
So for example:
- use Flag module to mark nodes, with one flag per site.
- use a CCK nodereference (this is my own setup, as I have a node type 'site' on the Distributing site where each node represents a site
- use a CCK field, such as a drop-down of text values
The existing nodequeue system could be carried over to this API for backwards compatibility.
Though I am not sure about its suitability, especially when contrasted with Flag:
- there are better UIs for picking nodes. With Nodequeue we're still waiting on #302671: Add to queue from Node edit form to streamline the process of adding and selecting a node; whereas Flag already presents the options in the node edit form.
- nodequeue is really meant for a system that requires nodes to be ordered. Here, we don't. Hence it seems a bit wasteful to use it, as well as being a needless UI confusion for end-users who may wonder what effect ordering their queue will have.
- nodequeues are identified by numeric ID. Flags have a string ID, which means they can be named for sites and the view arguments made easier to understand (and debug).
In terms of actual changes and work, I think this entails:
- uncoupling the nodequeue stuff into its own module
- adding an API for defining Views arguments on a Retrieving site: which services method to call to get the possible argument values
- folding admin/settings/retriever/types and admin/settings/retriever/queues into a single page that shows all the available Views argument selecting modules, lets you order them, and pick a value for each one. Same sort of UI as for Ubercart panel selection or my recent patch for Signup module.
- possibly an extra service method for admin sanity that checks that the View arguments on the Distributor are compatible with the Retrieving side. Or even better, fetch the whole View object and build the UI on the Retriever accordingly.
Thoughts, ideas, etc welcome! I may start on some of the groundwork over the xmas break, depends on the quality of the telly ;)
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 665230.content_distribution.content-retrieval-view-custom-arguments.patch | 42.68 KB | joachim |
| #8 | Content retriever - views admin settings ui.png | 42.62 KB | joachim |
| #4 | cont-dist-mockup.png | 54.44 KB | joachim |
Comments
Comment #1
greg.harveyI'm not very familiar with Flag, but your argument makes sense to me. I see no reason to object, as long as the D6 version always supports Nodequeues (or the Defaqto IT director will come after you with a gun when he has to dedicate half an iteration to switching to Flag). And anyway, the way you're talking about abstracting it to an API clearly means it will. As I say, we're kinda tied to making that API still work with Nodequeue, but it paves the way for people to add other sub-modules for Flag (or whatever else people might want to use that we haven't thought of).
Great to see some forward movement on this! =)
Comment #2
joachim commentedI've realized there's a potential big change in the current system, as currently, you select one or more nodequeues and one or more types, and the Retriever runs the view for each combination.
This approach of multiple views calls for multi-valued arguments could be included in the new system, but that's arguably not the ideal way to do it, as you're calling views.get TYPESxQUEUES times.
A better alternative might be a views argument handler that can take several types and queues in one argument (same as taxonomy can).
Comment #3
greg.harveyYou can already pass several types, I think... comma separated? I'd need to check. Not sure if the Nodequeue argument handlers support multiple values, but you might find it's already there and we simply didn't think of it!
Comment #4
joachim commentedThe UI is probably going to take a bit of a retrograde step, as I don't have time right now to make something ajaxy and fancy.
Here's a quick mockup of what I think would be cool though (nicked from the quicktabs module).
1. Pick a view (from a list of those on the master site).
2. *updates...* Pick a display.
3. *updates...* Create a list of arguments, picking possible values from each one.
Comment #5
greg.harveyGet you with the AHAH forms. I think that will be adequate. If I was doing it, we'd be talking Views 5.x-1.x interface time! :p
Comment #6
joachim commentedOh for now it's going to be pretty basic. I've currently got a 4-step wizardy thing that's just some 2nd level tabs with a redirect in each form submit -- like Panels 1 basically.
Comment #7
joachim commented... and actually, I am on TOTAL CRACK with that mockup.
The number, type, and order of the arguments is fixed by the view defined on the Distributor site. So there's no need for any of that quicktabs-style gubbins -- just a list of the arguments as retrieved by views.export, and widgets for selecting values where we know how to supply them.
Comment #8
joachim commentedList of changes:
- created a view settings tab
- moved view name to the first subtab of this
- added subtab for selecting a view display
- added subtab for specifying arguments: by default a plain textfield
- added a hook allowing modules to polish the selection UI for particular arguments
- added an implementation of this hook to provide a nice form widget for node types and nodequeues
- removed the nodequeue and node type admin tabs: these are now set on the arguments tab
- default view: nodequeue argument can take multiple queue ids
- removed installation system of new content types: the recommendation is now to use Features module to ensure they match across sites (and this was in fact merely a redirection to admin content type creation, with a hook-in to a custom unreleased module: see #709410: defaqto_content_type_installer
- added update function to convert the old variables for node type and nodequeue to the new single variable.
- big changes to the readme file.
I initially figured the three view settings subtabs could be later combined into a fancy single form with AHAH fetching the displays and arguments as you selected stuff, but since getting the information to make those form elements involves a service call, I think it may end up feeling sluggish to the user.
Committed the attached patch:
#665230 by joachim: Added ability to use any arguments in the content distribution view.
Here is a pic of the changed admin UI.