Download & Extend

Link operations on the node's Edit tab

Project:Node Relativity
Version:6.x-1.4
Component:Code
Category:feature request
Priority:normal
Assigned:Unassigned
Status:postponed (maintainer needs more info)

Issue Summary

For my application, I prefer to have the "Link operations" display on a node's Edit page (and not on the view page), i.e., on node/23/edit and not on node/23. I changed the module code as follows: I added in the Advanced Settings of the module for each content type a checkbox called "Show Link Operations in Node's Edit Form". If selected, the "Link operations" for this content type will be displayed on the node's Edit page.

The necessary changes in the code are small, here they are (there's also a patch file attached):

<?php
--- relativity.module 2007-03-30 00:10:28.000000000 +0200
+++ relativity.module   2007-03-30 00:06:55.000000000 +0200
@@ -581,6 +581,16 @@
            
'#description' => t('Use the specified relativity query to identify possible children.'),
           );
         }
+
+      
$group['node_'.$type.'_options']['relativity_linkops_in_edit_form_'.$type] = array(
+         
'#type' => 'checkbox',
+         
'#title' => t('Show Link Operations in Node\'s Edit Form'),
+        
'#return_value' => 1,
+         
'#default_value' => variable_get('relativity_linkops_in_edit_form_'.$type, FALSE),
+         
'#description' => t('Display the Link operations in the node\'s Edit tab (at node/34/edit, for example) or in the node\'s View tab (at node/34, for example).'),
+        
'#weight' => 20
+        );
+       
       }
     }
   }
@@ -
1104,7 +1114,8 @@
       }

      
// output links to attach allowed children types and remove existing children
-      if ($childrentypes = variable_get('relativity_type_'. $node->type, FALSE)) {
+      if (!
variable_get('relativity_linkops_in_edit_form_'. $node->type, FALSE) &&
+        
$childrentypes = variable_get('relativity_type_'. $node->type, FALSE)) {
        
$node->content['relativity_operations'] = array(
          
'#value' => theme('relativity_show_link_operations', $childrentypes, $node, 'view'),
          
'#weight' => 20,
@@ -
1115,6 +1126,24 @@
}

/**
+ * Implementation of hook_nodeapi().
+ *
+ * This is needed only in the case when the module settings indicate that the
+ * "Link operations" are to be shown in the Edit tab of the node.
+ */
+function relativity_form_alter($form_id, &$form) {
+  if (isset(
$form['type']) && $form['type']['#value'] .'_node_form' == $form_id) {
+   
$node = $form['#node'];
+    if (
variable_get('relativity_linkops_in_edit_form_'. $node->type, FALSE) &&
+      
$childrentypes = variable_get('relativity_type_'. $node->type, FALSE)) {
+     
$form['relativity'] = array(
+       
'#value' => theme('relativity_show_link_operations', $childrentypes, $node, 'view'),
+      );
+    }
+  }
+}
+
+
/**
  * Sorts an array of node types based on admin specification
  * @param an array of node type names to sort or empty to use precomputed $sorted_node_list
  * @return an array of sorted node type names, unindexed
  * @return an array of sorted node type names, unindexed
  */
?>
AttachmentSize
patch_relativity.txt2.33 KB

Comments

#1

+1 to hbfkf for sharing your patch :) but ...

-1 to commit this feature to the next official release of Relativity module ... because :

I'm beginning to understand that Relationships exist between nodes not in nodes. Keeping the Operator Links separate from the Edit Tab allows relationships to be modified by users without giving them full edit access to the parent node.

I can see a case for providing a Link Operator Rendering Option for a 'Relativity Link Operations' tab to sit along side 'View' and 'Edit' tabs. Would this be reminiscent of the 'Outline' tab from Book.module? ... and why not an optional 'Relativity Link Operations' block which would be visible only to users with the relevant permissions ?

Personally I prefer the Operator Links inline with the lists of Child Links etc because it is so much easier to edit in context (the reason behind WYSIWYG UIs). I believe Drupal will move towards inline editing where-ever possible (eg the jstools sub-module 'Activeedit'). In this respect, Relativity is ahead of its time and a to lose this major feature would be a deal breaker for many.

For controlling node relationships from the Edit Tab, you could just as easily use a CCK Node Reference Field (and build the Child List with an embedded view Filtered by that Node Reference List) or Taxonomy (again using views to build the embedded list of nodes linked by selected Terms). Both of these methods would give far greater flexibility in the kinds of relationships you could create between nodes compared to Relativity's simple uni-directional child-of-parent relationship.

#2

Thinking about it again, I completely agree to what you say. In order to obtain a little more flexibility as to where the link operations are displayed, I vote for your idea:

I can see a case for providing a Link Operator Rendering Option for a 'Relativity Link Operations' tab to sit along side 'View' and 'Edit' tabs. [...] and why not an optional 'Relativity Link Operations' block which would be visible only to users with the relevant permissions ?

So the admin would have (for each content-type) to option of displaying the link operations (a) at the current place, (b) in a tab alongside 'View' and 'Edit', or (c) in a block. Nah, what is the Drupal way of doing this? Would the module provide a block in addition to ((a) or (c))? Don't know enough about blocks (sorry).

#3

Relativity.module currently already provides (a) and (c) for link-lists of (1)Ancestors, (2)Parents and (3)Children. The blocks may be enabled in the (admin ->) Block Settings page. I guess this is the time-honoured Drupal way ... ;? I couldn't say how easy it might be to simply duplicate one of the other block functions (in Relativity.module) to build an additional block for (4)Link Operations ... ?

Currently the Display Options allow showing link sets in content and/or block or neither (in-content links are hidden if you set the list's (eg Parent) node weight to [0]) ... If we were to build a Link Operations Block, we should also provide (again by duplicating code) a Display Setting for the Link Operations filedset: 'Link Operations node weight' ... to allow for in-content invisibility at least! ... this has already been requested (somewhere) and would certainly solve a pressing problem with Omar's patch_4.

Now that particular themes can display blocks in / as content (rather than only in the sidebars - I'm thinking of Garland, and apparently Zen is even more flexible) this may reduce the need for future versions of Relativity to provide the in-content display option at all ... ? (a) becomes a subset of (c)... ;) but that's another story. It's funny, I like Relativity module because it does these UI features but I'm arguing that it dump them onto other modules & themes ;P

#4

Status:needs review» postponed (maintainer needs more info)

Inspired by this discussion, I added a "link operations" block option (http://drupal.org/node/133219). The idea of eliminating option a) altogether is very tempting, but let's wait a bit. Regarding option B (the edit tab): I would prefer not to implement it at all, because of the settings bloat. The new block can now be configured to appear for users with right permissions only.

I will leave this issue up for a week or so, so that you can convince me of the necessity for operations in the Edit tab.

#5

Inspired by this discussion, I added a "link operations" block option (http://drupal.org/node/133219). The idea of eliminating option a) altogether is very tempting, but let's wait a bit. Regarding option B (the edit tab): I would prefer not to implement it at all, because of the settings and code bloat. The new block can now be configured to appear for users with right permissions only.

I will leave this issue up for a week or so, so that you can convince me of the necessity for operations in the Edit tab.

#6

Inspired by this discussion, I added a "link operations" block option (http://drupal.org/node/133219). The idea of eliminating option A altogether is very tempting, but let's wait a bit. Regarding option B (the edit tab): I would prefer not to implement it at all, because of the settings and code bloat. The new block can now be configured to appear for users with right permissions only.

I will leave this issue up for a week or so, so that people can discuss the necessity for operations in the Edit tab.

#7

Version:master» 6.x-1.4

Is there a patch for this that will work on the latest version?