Hi all,
We had a specific use case here. We wanted to expose node queues over the Internet via web services, using the views.getView web service provided by the Services module. In order to achieve this, we needed the nodequeue module to expose a single view (instead of one per queue) which could accept the nodequeue Id as an argument. We have altered nodequeue (current attached patches, created with Winmerge, are against 6.x-2.0-rc1) so it does a couple of things:
* additional admin settings to say whether you want to expose a view per nodequeue or one view for all node queues (or both, or neither - it's checkboxes)
* available nodequeues as checkboxes on the node edit form, so you can check all the queues you want a node to go to during the create/edit process - it doesn't have to be a separate action any more
The code does still need work (e.g. at the moment it uses variable_set and variable_get instead of the nodequeue module's settings table, for speed and ease of deployment on our side) - what we'd like is to have this reviewed and to receive a 'to do' list from the maintainers, telling us what we need to do to get this committed so we don't have to maintain a separate patch. I believe these features are sensible additions that all will find useful. Hope you agree! =)
Work was done by Graham Taylor at Defaqto, btw, but he hasn't signed up to Drupal.org yet, hence me posting.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | nodequeue_multi_queue_view.patch | 20.46 KB | tayzlor |
| #3 | nodequeue_module_multiqueue_only.patch | 175.46 KB | greg.harvey |
| #3 | nodequeue_views_default_views_multiqueue.patch | 19.13 KB | greg.harvey |
| nodequeue_views_default_views_multiqueue.patch | 19.13 KB | greg.harvey | |
| nodequeue_module_multiqueue.patch | 4.37 KB | greg.harvey |
Comments
Comment #1
ezra-g commentedThanks for posting this.
To start, it would help if you submitted separate feature requests for each of these features.
Also, while it appears that these patches can be applied, it would be helpful if you followed the procedure at http://drupal.org/patch/create for creating patches in the future.
Comment #2
greg.harveyHi ezra,
Will create two separate requests (or rather, another one and rename this one).
Unfortunately there is nothing I can do about the patch situation. When I work from home I can submit patches in the proper way, but I am on a contract with a company using MS TFS (no patching built in) and CVS port is blocked so I can't checkout modules and use it to create patches against the repository either. =(
So you'll just have to bear with us on the patch thing while I try to convince IT to unblock CVS!
EDIT: Didn't know CVS could diff two local files as well. Will check it out tomorrow. Had I known, I would've used CVS to make patches all along.
Comment #3
greg.harveyThis feature request is specifically for the following feature:
* Nodequeue can be configured to present _either_ one view per queue or a single view that presents a nodequeue according to an argument in the form of the nodequeue qid
Patch code is attached. Apologies for the format - see post #2 above.
Comment #4
tayzlor commentedHi, Following #3 gregs comment. Here is the patch file for this feature request in the correct format.
Thanks
Graham.
Comment #5
greg.harveyAny news on this? Anyone able to review the patches? We're sort of on hold here. We want to re-roll them for dev, but not until we've had feedback, as there's little point in us re-rolling a patch the maintainers don't actually want.
Comment #6
ezra-g commentedI've been in touch with greg.harvey, and should be able to review this this weekend.
Comment #7
ezra-g commentedI don't understand the motivation of this feature. There is already a qid views argument, and it seems to support multiple values. Are you proposing that it should be possible to specify "all qids" as an argument, rather than individually specifying all individual qids?
In the interest of expediency, I will avoid requesting re-rolls on these patches if they simply no longer apply and can be tested against the version for which they were rolled. In addition to clarification, this needs work because the changes made here do not take into account the Views 2 API change (http://www.angrydonuts.com/attention-views-api-developers).
Comment #8
ezra-g commentedI found some clarification in #310177: Nodequeue web service - propose including in the nodequeue package: "We want to be able to know which nodequeues (and nodequeue ids) are available on a remote Drupal installation so we can use the Services module's views.getView method (with the nodequeue id as an argument to be passed) to retrieve nodes based on which nodequeue they are in using the multiqueue view"
So the feature request here sounds like it's to output a list of all queues/subqueues and the nodes they contain, or nodes and the queues that contain them, so that this can be used in conjunction with the services integration work at the above issue. I'll review that code for some clarification here.
Comment #9
greg.harveyEDIT: I see you found more detail - yes, that's broadly it. =)
Hi Ezra,
Thanks for looking at this. Perhaps we didn't understand what was already available.
Our brief was to expose the contents of a nodequeue over a web service and filter that queue by content type, e.g. another application needs to be able to say "Send me all the 'page' content in nodequeue 1".
The easiest way to achieve this was to use the Services module's existing view.get method and expose a view with the content we wanted.
But when we first looked at Nodequeue, the only views it appeared to support were dynamically created for each queue, with no arguments available (e.g. nodequeue_view_1 returns all content in qid 1, nodequeue_view_2 in qid 2, nodequeue_view_n, etc.) and nothing else. We created this code to expose a SINGLE view (the multiqueue view) which you can pass a nodequeue qid to as an argument, rather than having dozens of views cluttering up Views admin. While we were at it, we also added the ability to filter down to a specific content type in a queue as well (a requirement of ours) so optionally you can pass qid and content type as arguments.
Perhaps this crosses over with something written since? If you're saying this has been created already, or there was something there that achieves the same thing we could've used instead, then we stand corrected.
Hope that clarifies.
Comment #10
tayzlor commentedhi ezra-g,
are we duplicating functionality here, do we need to amend this patch?
Comment #11
ezra-g commentedI'm sorry about the delay here -- Perhaps we've discussed this in IRC and just not updated the issue. In any case, after re-reading this issue, I have to point out that Views has an "allow multiple" argument, that would allow you to pass in multiple QIDs. You can also have a second argument to filter on type, and create a service that passes service query parameters to those Views arguments. I'm marking as fixed, but please re-open if that doesn't satisfy your use case.