Generalize to entities

This falls under the heading of allowing any no-node object to be contained in a queue. At this point, Nodequeue is highly specialized towards nodes and would have to be re-engineered to support non-node objects.

If you want to have a queue of user profiles, you could have profiles as nodes. Another potential solution would be to use the flag and flag_weights modules.

I'm leaving this open as a feature request.

Probably duplicate of: #1154536: Allow Queues of Entities other than Nodes.

Actually, #1154536: Allow Queues of Entities other than Nodes is the duplicate, so I closed it.

A very nice feature to take into consideration in this rewrite process: #247845: Queue Revisions.

If you're interested in this issue you'd also likely be interested in this sandbox: http://drupal.org/sandbox/davereid/1240856. No code checked in yet however.

Very interested! Subscribing.

subscribing

subscribe

http://drupal.org/project/relation Provides ability to create arbitrary lists of entities. Yes i know the module is built for "relation" functionality. but do not overlook that "list" is yet another relation.

Many "node queue" features are lacking from relation module (such as ability to set explicit order of entities within a relation list, as well as various UI tools to aid creation and administration of relations similar to NQ) but would be easy to create as an add-on module.

I am using relation module right now as means of 'entity queue/list' :)

Hrm. Interesting point, litwol! See particularly #1304196: How should we do weighted Relations?. This seems like the best use-case I've seen so far for that issue.

How about just combining Draggable Views (for the admin) and Flag for the on-page ability to mark content? And they're exportable.

I finally decided to publish my starting code for the Entityqueue project. You can find it at http://drupal.org/sandbox/amateescu/1429904 and in the following days I'll start creating tasks for what needs to be done in order to reach feature parity with Nodequeue.

subscribing

Per #12, using Draggable Views is, in my opinion, the best option.

See also Entity collection

That's a very interesting of ideas in those posts, however, when I see the archive sizes of differents codes : I see nodequeue is more than 300kb, Entity collection about a tenth of this size, and relation a fifth and seems to do so much.

My question is : What makes the code of nodequeue to be so big ? I wonder if the module is not outdated and deprecated at carrying an old "node thinking way" whereas finally in D7, the entity concept came up to bring some simplifications which could explain, indeed, the difference in terms of code size.

Can someone clarify ?

@jmary:

You'll find quite a few png screenshots in the nodequeue codebase. This accounts for the difference in files sizes of the modules.

@amateescu What are your plans for Entityqueue in relation to Nodequeue? Will we generalize to entities in Nodequeue, or rely on Entityqueue for that functionality?

Yes, I would prefer to direct all efforts to Entityqueue, mostly because the project name is a better fit for the scope of generalization to entities :)

Sounds good :) I added a short description of Entityqueue on the Nodequeue project page.