Manually applying weight to relations which can be used in views or elsewhere to order relation related displays.

Ideally long/medium term we'd provide a drag and drop UI - in the short term, what should be the standard way of doing it that this UI builds on?

There's plenty of precedent for manual ordering of nodes, in the context of taxonomy lists and others - in fact, there's a list comparing 6 modules that do this in different ways.

It's already possible to do basic relation-based ordering in an improvised way. You can create an integer field 'Weight', fill in some values by hand, and set up a view that gets this field and sorts by this field. It's fine, but filling in integers by hand to a views field is clunky. It'd be great if:

  • either... We could set a standard way of weighting relations, then have a simple ui module bundled with relation (Relation Weights maybe) that provides a drag and drop widget...
  • or... We could integrate with one of the node-sorting modules above which already provides a widget - maybe nodeorder which appears to be already geared for node-taxonomy relationships?

Some example use cases for manually ordering relations:

  • Node-node: to allow ordering of recommended content, or ordering items within more sophisticated book-like groupings.
  • User-node, "Team member" then you order people's positions in the team. People can be in any number of teams, and teams can be re-ordered.
  • Node-taxonomy: in e-commerce stores, items often have multiple categories where some are better fits than others - as well as ordering them based on good fit, you might want to highlight those above a certain weight in the display.

Comments

alanom’s picture

apologies for the nodeorder link... I foolishly believed the list page when it said nodeorder had a drupal 7 dev version. Maybe Weight or Draggable Views are better initial projects for comparison.

Strangely, it seems none of the 6 weight modules simply use D7 entity/D6 CCK fields for weight - maybe there's something already in D7 that I've overlooked?

dpi’s picture

I have implemented Relation weights on a project. At first the idea of adding a order field to a relation type seemed natural, but I wanted each endpoint on the relation to have its own separate weights.

The way I have it right now is, I have a integer field on the endpoint type, with unlimited cardinality. The item values for the field are relation ID's.

In postprocessing of a list of relations, I apply the the weights' values.

It works great for my purpose.

I think this kind of functionality would be best separate from core Relation, ie: contrib.

alanom’s picture

That makes a lot of sense. I hadn't considered cases where you might want different weighting from the source or target of a relation. It makes sense to administer relation weights by direction from the endpoint entity that the relation is going 'out' from, and it makes a lot of sense to use the existing field sorting UI.

This does sound like a good basis for a module. Would you be willing to share what code you have as a starting point?

I'm trying to think what functions a polished, shiny final-version module for this would have (I'm no expert so please forgive any mistakes):

  1. On install, defines 'Relation Weight' field type modeled on Integer. Each field on a content type/entity is assigned to an existing relation type
  2. Simple UI widget for relation field that uses the IDs to find and print the names and entity types (and, for nodes, content types) of the outward endpoints plus for asymmetrical relations the wording used for the relation's direction, so users sort comprehendable lists of endpoint entries like "Has course content: Using Relation module (Node: Tutorial)" instead of cold IDs
  3. Some hook on relation save, delete etc, checking the endpoint entities of the relation for relation weight fields configured to this relation type, and if it finds them, adding or removing an instance of the field with this relation's ID
  4. Views integration offering fields and sorts where the relation weight field content matches the ID of a relation that takes the entity as the source of a relation relationship - not sure how difficult this might be to implement.

Building on this, if we're giving the user a sortable list of relations of type X on an entity's edit page, it seems intuitive to then add an [x] ajax button to each row allowing that relation to be deleted, [edit] links for any relation fields allowing that relation's fields to be configured, and a form input (autocomplete field maybe, with direction switch for asymmetrical relations?) to allow new relations of type X to be added and appended to the list - and then suddenly as well as easy to manage direction-specific weights, we've also got a simple, concise, intuitive UI where a user can easily manage all an entity's relations of type X from that entity's edit page!

naught101’s picture

Status: Active » Postponed

I think this is definitely more of a separate module kind of thing. Feel free to discuss stuff here, please mark as fixed once someone starts a project.

naught101’s picture

Status: Postponed » Closed (duplicate)

marking as duplicate of #1304196: How should we do weighted Relations? because that's more understandable (diagrams!).