This request is probably an edge case, but it's something I was trying to accomplish today. I don't know if this is a limitation of CCK or something your CCK handler can manage - I've only looked at the code briefly.

Here's my guess about why shared CCK fields don't work.

Situation: I have three different content types. They share a common CCK (int) field named "sequence". CCK creates a new table for shared fields and takes the field out of the main content table for that content type. Records in this shared table are ONLY created when the related record has data for that field. The problem then, is that DraggableViews doesn't have a correlated field as it would if it were in the same table as the content type.

DraggableViews works when the CCK field is within the content table, but breaks when the field becomes shared.

Because there's no 1-to-1 match for each node to the shared table (e.g. content_field_sequence). _draggableviews_ascending_numbers() kicks out it's "Something wrong in _draggableviews_ascending_numbers".

The current solution is to simply limit your use of CCK fields (using DraggableViews CCK handler) to fields which are unique to that content type.

Ultimately, I'm fine with DraggableViews maintaining my hierarchy for me across multiple content types. The problem then becomes accessing that content. DraggableViews would need to provide a Views Relationship where you could specify the view you wanted to pull the Order or Parent id values from.

This would invoke potential cross over, when some silly user creates more than one Draggable view of the same content, but this could be mentioned as a caveat.

I'm really digging your module here. I'm using it in a totally obscure way where I need to facilitate easy reordering of site content on a Drupal site which is pulled from via Services's XMLRPC by way of Java/Groovy. The problem is accessing the Order/Parent values (when the specified cck field is shared).

Of course, I'll be using the temporary solution of making unique fields on each content type.

From the looks of what you've got started here, you might want to consider breaking out the hierarchy part. Hierarchy API anyone? /contributions/hierarchy is taken but it's an older d5 mod. Of course hierarchies and hierarchyapi are available. ;)

What do you think? Worth the effort? I'm guessing I won't be the only one trying to specify a cck field which is shared.

Comments

sevi’s picture

sevi commented

Please help me understanding your request.
I tried using shared CCK fields in 2 content types. I manually deleted a record of the shared table and reloaded my draggable view: Everything seems to work fine.
The LEFT JOIN of views module returns NULL -> the "structure is broken" and the record gets inserted in the database table again.
I'm afraid I missed the point O_o.

And why would you break out the hierarchy part?

mattman’s picture

mattman commented

I think I may have found the issue. I got things working with shared cck fields (when those fields are used in multiple content types) - but ONLY when the records existed and had a pre-existing value in the field being used for the order.

First, maybe it was my setup. I was using Views 6.x-2.3, CCK 6.x-2.2, DraggableViews 6.x-3.2-beta4. I updated to Views 6.x-2.5.

Secondly, it seems that the shared table MUST have pre-existing values in the order field. Maybe I missed this in the documentation.

I dug through your code and I see that you're relying on node_save and not running your own SQL (which I was assuming you were). As you parse through the array of items from the view, it's handed off (obviously, when using a CCK handler) to node_save, which in-turn defers to cck to manage it's fields.

As a test, I used devel to create my content items (which included the sequence field [what you define as order field]) and it populated this field in the shared table. This got DraggableViews working with the shared table - Yeah! Success. However...

As an experiment, I randomly deleted some of the fields for that content type in that view. DraggableViews did repair the hierarchy - another good thing. The next test was to simulate the setup I had when I first started using DraggableViews. I deleted all of the records within the shared table. This replicates what a new user might experience with Draggable Views.

This situation is such that, upon installing DraggableViews, when you add the CCK field 'after the fact' to be used with DraggableViews and the content type does not have any pre-existing records for those content items listed in the view, DraggableViews is not able to order the records. At least not as far as Ican tell. I've not yet been able to make it happen. I'm assuming it's because there are not values existing and cck is not inserting values when they don't exist.

Your test to replicate would be to go in and delete all the records in the shared cck table. This is how I was initially setup.

As soon as I create a matching record for each node (shown in the view) within the shared cck table, everything started working again.

I used a subquery to reset values in the shared table after deleting all the records.

INSERT INTO content_field_sequence (SELECT nid, vid, nid FROM node WHERE type="podcast_episode")

Functionally, your code works fine when everything is in order. When the expected fields do not exist in the shared content table, then things seem broken and you continually get the "repaired" message. This is likely a user experience issue and not one related to the code functionally working as you're expecting.

The test sequence is this.

1. Create a content type and add new content (to be used in the View)
2. Create the View
3. Enable DraggableViews
4. Add the CCK shared field to your content type (make sure it's used by more than one content type)
5. Edit the view and change the style to Draggable Table
6. Specify the shared cck field as the order field and set the CCK handler

Presuming there are no records in the shared table, you should hit the issues/errors I was having.

I hope this helps out and is better clarified.

Matt

P.S. I'll be doing a video about your module on GotDrupal.com at some point in the future. Great work on a very powerful tool!

P.S.S. The idea of breaking out the hierarchy to something like Hierarchy API would serve many benefits. Currently, you're tightly associated with a View when using a native handler. If you broke out the Hierarchy aspect (by abstracting based on something like the object the hierarchy is for) and made it into an API, you could manage hierarchies for many other things. Users, Nodes (independant of Views), Views of nodes (which you're doing now), supporting external management of a hierarchy via Services module and any other use case that may pop up - all these would extend what you've already started. You're simply abstracting the hierarchy aspect and letting the DraggableViews ride on top of that. Make sense?

mitchell’s picture

mitchell commented
Status: Active » Closed (duplicate)

@mattman: I think the bulk of your comments relate to data collisions and how to interact with the hierarchy directly. #357426: Cannot create structure manually / cannot work with existing structures speaks well to those issues.

Another way forward could be to break your issue down into separate ones. I'm not 100% sure what this issue is about, because the hierarchy api seems like an interesting discussion, but it's getting lost in the original intent of the issue.

sevi’s picture

sevi commented
Status: Closed (duplicate) » Closed (fixed)