Posted by sjf on December 11, 2008 at 9:29am
4 followers
| Project: | DraggableViews |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Has anyone managed to get this to work with Panels? I have a page with two panel panes, each with a different draggable table view. When I drag items in the first pane it saves fine. When I drag items in the second pane, I get the weight collision error, refresh and all nodes in both the first and second panes are reset. If I don't have any nodes in the first pane, the draggable view in the second pane saves fine.
The first pane is used to sort one node type, the second a different node type. I was using the same weight integer field for both, and tried changing it to two separate integer fields (with allowed values of -50 to -1 for the first node type/pane, and +1 to +50 for the second) but this didn't work either.
Any thoughts?
Comments
#1
I came across the same problem. I was trying to get two different draggableviews in different panel panes and I got the same exact results. It turns out that it doesn't actually have to do with panels. Loading the draggableviews' as blocks on the same page results in the same issue. The one that gets loaded first wins (in terms of functionality).
The problem has to do with the form_ids that are created by the module. In this case, both views get generated in different html forms but the forms end up having the same drupal form_ids (check the form tokens and you can see that they match). I ended up resolving the issue by tampering with a couple of different files but I am not sure how to modify what I did for a more general case. I will explain what I did and maybe someone can see a way to make the process much cleaner.
The problem revolves around the call to drupal_get_form() in draggableviews_plugin_style_draggabletable.inc.
function render() {// call form handler to wrap around a form.
// -> this makes it possible to submit changes.
return drupal_get_form('draggableviews_view_draggabletable_form', $this);
}
Here the form will always create the form_id of draggableviews_view_draggabletable_form. I modified this here:
function render() {global $form_counter;
$form_counter++;
return drupal_get_form('draggableviews_view_draggabletable_form' . $form_counter, $this);
}
I couldn't figure out where to place the $form_counter variable so I defined it on my main template page.tpl.php:
<?php $form_counter=0; ?>This will create a unique id for each draggableviews form that is created. However, I had to implement hook_forms() so that drupal would know how to handle the forms. In draggableviews.inc I added a function:
/**
* Implementing hook_forms
*/
function draggableviews_forms() {
$args = func_get_args();
$form_id = $args[0];
if (strpos($form_id, "draggableviews_view_draggabletable_form") === 0) {
$forms[$form_id] = array('callback' => 'draggableviews_view_draggabletable_form');
}
return $forms;
}
This gets the form_id and checks to see if we are dealing with a draggableviews form. If so, it points to the main form processor (which also needed modification). My main form function ended up looking like this:
function draggableviews_view_draggabletable_form($form_state, $view) {
$form['submit'] = array(
'#type' => 'submit',
'#value' => t('Save'),
);
$form['#submit'][] = 'draggableviews_view_draggabletable_form_submit';
return $form;
}
I added the #submit directive so that it knows to submit the form to the draggableviews submit function. The good news was that the forms were being generated as expected but the views were no longer showing up. It turns out this was a thememing issue. Basically, knowing that I only needed to have two draggableviews show up (for now) I modified the draggableviews.module file by adding two more elements in the draggableviews_theme() function's return array with names that corresponded to my form_ids.
function draggableviews_theme() {return array(
'draggableviews_ui_style_plugin_draggabletable' => array(
'arguments' => array('form' => NULL),
),
'draggableviews_view_draggabletable_form' => array(
'template' => 'draggableviews-view-draggabletable-form',
'arguments' => array('form' => NULL),
),
'draggableviews_view_draggabletable_form1' => array(
'template' => 'draggableviews-view-draggabletable-form1',
'arguments' => array('form' => NULL),
),
'draggableviews_view_draggabletable_form2' => array(
'template' => 'draggableviews-view-draggabletable-form2',
'arguments' => array('form' => NULL),
),
);
}
Doing so meant that I had to add two more function to the preprocessing of the theme in draggableviews_theme.inc. So I duplicated the function:
function template_preprocess_draggableviews_view_draggabletable_form($vars)twice and just post-fixed the function names with '1' and '2', respectively.
function template_preprocess_draggableviews_view_draggabletable_form1($vars)function template_preprocess_draggableviews_view_draggabletable_form2($vars)
I then duplicated the theme file draggableviews-view-draggabletable-form.tpl.php twice and post-fixed the file names with '1.tpl.php' and '2.tpl.php', respectively.
After doing all of this, I am now able to get two draggableviews instances on one page (in different panes or in separate blocks). I know my process is rather clunky but I was able to get the job done. Does anyone else have any ideas on how to possibly streamline the process and possibly turn it into a patch?
#2
Right, the inline-comment says it (in brackets):
http://api.drupal.org/api/function/drupal_retrieve_form/6
After your great work it was easy to continue and I ended up with the attached patch.
Now a theme function will be registered for each view which isn't disabled. I'm not entirely happy about this solution because most of these theme functions will never be used. Maybe someone else can improve this in the future.
Instead of the form_counter I used the view-name. Now all the "template" properties point to the same template and the "preprocess functions" properties point to the same preprocess_function. (..for the most-general use :))
greetings,
sevi
#3
I forgot involving a file in the patch..
next try :)
#4
Anybody out there who agrees that this issue is fixed? :)
#5
trying the patch now...
#6
I agree
#7
Let's say this is fixed.
#8
Automatically closed -- issue fixed for 2 weeks with no activity.