As the current services integration is no longer compatible with services 3.x and had just a few functions anyway, I wrote a new one.
Hope it will be helpful to others
I attached a patch for the current nodequeue_service implementation and a tarball (because who knows how long it will take untill it's may commited, I need it now anyway ;) )
functions:
- retrieve_queues Retrieves an array of available nodequeue objects.
- retrieve_subqueues Retrieves an array of available sub-nodequeue objects.
- retrieve_queue_items Retrieves an array of all nodequeue nodes.
- add_queue_item Adds a node to a nodequeue.
- remove_queue_item Removes a node from a nodequeue.
- get_queue_item Retrieves a node at a specific position of a nodequeue.
- shift_queue_item Shifts and returns the next item of a nodequeue.
btw: if interested, I'd like to continue further integration of rules and services as co-maintainer
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | nodequeue_services.tar_.gz | 908 bytes | lucascaro |
| nodequeue_service_services3-x_integration.zip | 2.68 KB | patrickd | |
| nodequeue_service_services3_x_integration--0.patch | 13.92 KB | patrickd |
Comments
Comment #1
amateescu commentedI requested feedback on this patch from someone who worked on nodequeue services integration, and her comments are here: #1045678-6: Add a service for saving the contents of a subqueue. I'll try to contact dixon_ too and see how we can push this forward :)
Comment #2
lucascaro commentedHey guys, I'm working on this as well and It would be great to be able to join forces :D
Although I'm afraid the solution proposed on the patch needs some rethinking since it's using the same rpc-oriented architecture than services 2.x.
Services 3.x is resource oriented and basically the idea is to add resources and crud operations (the idea and justification is explained here: http://www.slideshare.net/hugowetterberg/services-drupalcamp-stockholm-2009 which is referenced in the services 3.x documentation). This way nodequeue would have a great integration for both xmlrp and REST servers.
From what I see here, we could have the following resources:
Resources:
Basically I see that the proposed actions could be performed using the above resources as follows:
This would be a call to queue.index that returns all the nodequeue objects.
This would be a call to queue.subqueues that returns all the nodequeue objects.
This could be a call to queue.items, which whould return a list of items in the queue. We can return nids and the node information can be queried using the node resource.
This can be a call to queue.add_item, passing a nid and a nodequeue id or machine name.
This would be a call to queue.delete_item.
This could be done as a parametrized call to queue.items where we pass the position as a parameter.
This would be a call to the queue.shift_item targeted action.
I'll start a sandbox project for this so I can start coding, but please let me know what you guys think!
The need for a subqueue resource depends on whether subqueues are nodequeues or not (I'm not familiar enough with that) but if we wanted, we could manage them with the same nodequeue resource, which would simplify things a lot.
Comment #3
jesse.d commented@lucascaro
Did you ever make any progress on this? I'm interested in a nodequeue service myself and was wondering if there was anything that I might do to help out.
Comment #4
lucascaro commented@jesse.d I finally decided to not use nodequeues via services (for unrelated reasons) so I'm not going forward with this module. I did some development though and I'm attaching what I have, which is trying to implement what I've proposed here.
This code would need a lot of testing and polishing though and I'm only posting it in case it helps a developer to get something usable.
I hope it helps.
Comment #4.0
lucascaro commentedadded functions