The current module works well for me, but appears to require that the ordering is by a CCK field, while this could be generalized a bit more, by just requiring a views-sortable field and allowing modules to perform their own "save" of the update hierarchy. This feature requires two changes:

- generalize _draggableviews_filter_fields() to allow any field that supports a sort handler

- generalize _draggableviews_save_hierarchy() to call a user hook before falling through to the current behavior (which might need some more error checking once the list of fields is expanded).

Example application: "Flag" module is the successor to "Views Bookmark", which allows users to tag nodes, and display that list of nodes using Views. By adding a "weight" field to the flags table, and making the two changes above, I was able to use draggableviews to allow the user to reorder their flags. I can provide code if module maintainer is interested.

CommentFileSizeAuthor
#5 draggableviews_flag_weights.tar_.gz1.48 KBlyricnz

Comments

sevi’s picture

sevi commented

That sounds good.
As far as we keep the default implementation of CCK-Fields I'm looking forward to this modification.

You're welcome to provide as much code as you want ;)

Greetings,
sevi

sevi’s picture

sevi commented

Hey lyricnz,

the obligatory CCK-fields were ugly in my eyes anyway :)
With the next release draggableviews-handlers will be introduced. So other modules can implement their own handlers which handle saving the order/parent information. At the moment all fields are allowed (no filter). A specific handler can be chosen for each field individually.
For more detailed information look at implementations/draggableviews_handler_auto.inc or modules/draggableviews_cck/draggableviews_handler_cck.inc

The next development snapshot will contain these changes.
Please try and report back.

lyricnz’s picture

lyricnz commented

I just tried the latest -dev release, and it seems to be working fine (although the UI is thoroughly confusing, and the code has some coding-standards issues). I implemented a Flag Weights handler, which seems to be working fine.

Do you think that should be part of Flag Weights module, or this?

criz’s picture

criz
he/him
Location Vienna/Austria
commented

This sounds great! Good work sevi and lyricnz, will test it as soon as possible...

@ lyricnz
What coding standard issues are you referring to? At least I'v found no problems with coder module any more... :)

lyricnz’s picture

lyricnz commented
StatusFileSize
new draggableviews_flag_weights.tar_.gz1.48 KB

Re: coding standards
I probably got the -dev release before your latest set of changes - http://drupal.org/cvs?commit=163643

I've just added support for this to Flag Weights module (dev).

- enable Flag + Flag Weight module
- create a new Flag (eg "cool stuff"). tag some nodes with it.
- clone the Views created by flag module, change it to Draggable Views, and add the Weight field from the relationship. Sort by this field.

I'll write up a more detailed tutorial when I get a chance.

sevi’s picture

sevi commented

I'll try to make the UI more usable. I haven't really covered this yet.

In my opinion it should be definitely part of Flag Weights module, because the only reason for it comes with that module.

sevi’s picture

sevi commented

Wow, that came really fast :)
I tried Flags module in combination with Flag Weights and draggableviews and was happy to see them working together. Pretty cool.

Concerning the handler definition: do you think there should be an additional field "supported fields" with the definition?
Then draggableviews would check the compatibility (what you currently make in the init function

class draggableviews_handler_flag_weights {

  function init($field_name, &$view) {
    // Check that the handler is being used on the right type of field.
    if ($view->field[$field_name]->table != 'flag_content') {
      drupal_set_message("This handler cannot be applied to this field - use Weight!");
    }
...

).
Or are these checks too individual and complex?

lyricnz’s picture

lyricnz commented

Agree the init() is a bad place for this - by the time you get to that, it's too late. Perhaps each handler could be given the view fields, and return which fields the handler could be applied to? Then maybe you could use this information in the UI to limit the set of fields as options for each handler.

I was initially confused by your "auto" weight field, which doesn't seem to "automatically" do anything - it's a new table that contains the data. Perhaps a better name would be "native" or something, but I don't know.

sevi’s picture

sevi commented

Hm,
true, maybe while continuing the ability to mark it as "unrestricted".

The label "auto": When I wrote this I thought about "nothing else to implement, saving just automatically managed by the module", but you're definitely right, it's confusing. "Native" sems good to me, I think I'll take it.

lyricnz’s picture

lyricnz commented

What's "unrestricted" mean?

sevi’s picture

sevi commented

..that a handler (which is marked as "unrestricted use") can be used for any kind of field, without limitation. But I'm still thinking about a reason why this can be useful :)

lyricnz’s picture

lyricnz commented

Surely that's not a special case, but just a handler that returns all the fields? (or, if you like, not implemented the "getSupportedFields" method.

lyricnz’s picture

lyricnz commented
Status: Active » Fixed

I'd say this is "fixed", since it is delivered, and there is a third-party module that uses it ;)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.