Hi,

This is about making HS work with the "noderelationships" module , which opens a "modal frame api" window where you can select nodes to reference which are displayed by a view. In my case the nodes to reference should be filtered by a HS taxonomy filter. I thought I'll share my experience, since it took me quite a while to figure out what was wrong. It's a quite dirty fix, but it works. I'm new with drupal, don't understand lots of stuff about it's structure, but I had to get this done fast for a job, so... Maybe somebody with a better understanding of drupal can translate this into proper code...

What I did:

1. Include this line of code:

module_load_include('inc', 'node', 'node.pages');

at the beginning (first line) of function "hierarchical_select_json()" in the hierarchical_select.module file. Otherwise the form would not get built right and nothing would work.

2. Add the following lines to the "update" function in hierarchical_select.js

Drupal.HierarchicalSelect.update = function(hsid, updateType, settings) {
  var post = $('form:has(#hierarchical-select-' + hsid +'-wrapper)', Drupal.HierarchicalSelect.context).formToArray();

  // ROD'S HACK: attach noderelationship's views arguments to post
  if ($(".noderelationships-noderef-page-tabs ul li a").size() > 0){
	  var node_ref_path = $(".noderelationships-noderef-page-tabs ul li a").attr('href');
	  var node_ref_args = node_ref_path.split("/");
	  post.push({ name : 'field_name', value : node_ref_args.pop() });
	  post.push({ name : 'referrer_type', value : node_ref_args.pop() });
  }
....

3. Changed the function "hs_taxonomy_views_json" in hs_taxonomy_views.module to look like this

function hs_taxonomy_views_json($view_name, $display_id) {
  
  $view = views_get_view($view_name);
  
  if ($view != NULL) {
  	if (isset($_POST['referrer_type']) && isset($_POST['field_name'])) {
  		$view_args = array ($_POST['referrer_type'], $_POST['field_name']);
  		$view->execute_display($display_id, $view_args);
  	}else{
    	$view->execute_display($display_id);
  	}
    views_set_current_view($view);
  }
  return hierarchical_select_json();
}

3 + 4 are pretty dirty, I know, but I figured that the noderelationships view would not get built without those two arguments. Maybe somedoy knows how to pass those arguments without having to "post" them through jquery to the "hs_taxonomy_views_json" function.

4. apply this patch, otherwise the filter's javascript would not work when the view is reloaded after applying a filter.

Hope somebody finds this useful ;)

cheers,

rodrigo

Comments

Wim Leers’s picture

Project: Hierarchical Select » Node Relationships
Version: 6.x-3.x-dev » 6.x-1.x-dev

The patch you're referring to in step 4 has already been committed.

Step 1 implies a bug in the noderelationships module (the noderelationships module should include that file already).

Step 2 is supported by HS without hacking it. Consult API.txt's "JavaScript events" section for an example.

Step 3 … is it really necessary? Can't Views automatically accept those arguments? In any case that is a Views problem, not a HS problem.

In summary:
1) issue with noderelationships module
2) you'll have to write some more code to support that — maybe that also belongs in the noderelationships module?
3) unrelated to HS
4) fixed

So, for now I'm moving this to the noderelationships issue queue.

markus_petrux’s picture

Status: Active » Postponed (maintainer needs more info)

I'm not using HS, so I can only guess for the moment...

@rodrigoderteano: NR loads node.pages.inc to build the node add form, so I'm not sure which is the problem. You're saying it does not work, and what you had to do, but you're not saying which was the problem. So I'm not sure where to look. Could you please describe step by step instructions to reproduce the issue and which is the exact problem?

BTW, it seems to me I should only focus on step 1, so please correct me if there's anything else.

rodrigoderteano’s picture

Hi there again,

yes, most of those issues are not HS issues (just posting them in case anybody has the same trouble). Perhaps only number 1 is a HS issue. The problem appears when I try to use HS inside a modal frame api window opened by the noderelationships module. When I try to select something with hs, javascript tells me: "Received an invalid response from the server".

After I reload the page, I get the following error message:

* warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'node_form' was given in /home/mauricio/public_html/culturaperu.pe-tester/includes/form.inc on line 371.
* warning: uasort() [function.uasort]: The argument should be an array in /home/mauricio/public_html/culturaperu.pe-tester/includes/common.inc on line 2875.

Searching for the first warning in google, I found this: http://drupal.org/node/322163.

That's why I included

module_load_include('inc', 'node', 'node.pages');"

at the beginning of "hierarchical_select_json".

Seems like otherwise the form would not get built right. The error appears only inside the "modal frame api" context, so I guess I'll post the bug over there. Sorry guys for the inconvenience and thanks for your time.

rodrigo

markus_petrux’s picture

Node Relationships (NR) module already loads node.pages.inc to properly build the node add form, so it seems this could be related to the way HS deals with the form to process the AJAX request. I think it could be something there because other AHAH requests work perfectly well with NR. For example, the "Add more items" buttons for CCK multiple value fields or multigroups. In fact, the multiple selection button used by "Search and reference" option of NR uses this technique to rebuild the multiple values widget after a multiple selection has been submitted from a modal frame dialog.

I'm afraid this needs to be debugged with both modules installed to why the error fires.

markus_petrux’s picture

Project: Node Relationships » Hierarchical Select
Version: 6.x-1.x-dev » 6.x-3.x-dev
Status: Postponed (maintainer needs more info) » Active

I've been trying to debug this issue, and the problem seems to be related to the way HS deals with cached form data in hierarchical_select_json(). Since it uses its own cache, it cannot retrieve the from from FAPI cache and it needs to directly rebuild the form from scratch. To do so, it tries to solve the problem of required includes by capturing the file attached to the menu callback when the form is built initially, but it fails to capture other files that may be required.

Node Relationships module builds the node add from from noderelationships.pages.inc, which is the file captured by HS, but NR also needs to load node.pages.inc to perform its own task, so to build the node add form, there are 2 files that HS would have to load from hierarchical_select_json() before calling drupal_retrieve_form.

Note that this problem does not happen with AHAH callbacks attached to "Add more values" button is multiple value fields in CCK, or FileField stuff. These AHAH callbacks use FAPI cache to retrieve the form and capture form state. This makes me believe the problem here lies in the land of HS.

Wim Leers’s picture

Status: Active » Postponed

I've been trying to debug this issue, and the problem seems to be related to the way HS deals with cached form data in hierarchical_select_json(). Since it uses its own cache, it cannot retrieve the from from FAPI cache and it needs to directly rebuild the form from scratch. To do so, it tries to solve the problem of required includes by capturing the file attached to the menu callback when the form is built initially, but it fails to capture other files that may be required.

It actually uses the Forms API cache as well. But it's useless to HS, because of a myriad of reasons. It's late, but IIRC, it was necessary for Views exposed filter form support as well as the simple fact that #process callbacks wouldn't be called in Drupal core's AHAH form updates.
Believe me, when I ported to Drupal 6, I was expecting to be able to rip out a whole bunch of my code, related to the form cache. It seemed impossible. I talked to many people, including merlinofchaos, and we all came to the same conclusion: because of HS' unusual nature (the only complicated AHAH form element for Drupal), core's functionality was not sufficient.
I *wish* I could just use Forms API in a simple way. I can't :( Forms API is not designed for AHAH form elements. It needs a major revamp first.

Node Relationships module builds the node add from from noderelationships.pages.inc, which is the file captured by HS, but NR also needs to load node.pages.inc to perform its own task, so to build the node add form, there are 2 files that HS would have to load from hierarchical_select_json() before calling drupal_retrieve_form.

Odd, many modules that supposedly didn't work with HS, didn't work because they indeed forgot to include node.pages.inc (or user.pages.inc). That includes Content Profile, FileField and the likes. So it seemed obvious this case was similar. Apparently it's not.

Note that this problem does not happen with AHAH callbacks attached to "Add more values" button is multiple value fields in CCK, or FileField stuff. These AHAH callbacks use FAPI cache to retrieve the form and capture form state. This makes me believe the problem here lies in the land of HS.

They've been fixed because of the bugreports filed here in the HS issue queue :P

I'm postponing this issue because I really don't have the time to build a whole setup so I can test this. I'll gladly accept patches and investigations though.

markus_petrux’s picture

I ended up coding a different method to build the node creation form within the Modal Frame using the regular node/add/[type] path.

#668922: Redirect to node/add/[type] when creating nodes within the Modal Frame (the patch is not trivial, I would recommend waiting for the next dev snapshot).

Maybe that fixes this issue?

Wim Leers’s picture

Status: Postponed » Postponed (maintainer needs more info)

Asking for info from the users.

AgaPe’s picture

The way Rodrigo did it didn't work for me...

Wim Leers’s picture

Issue tags: +compatibility

So this issue is kind of stuck. Tagging as "compatibility" issue.

Wim Leers’s picture

Status: Postponed (maintainer needs more info) » Closed (fixed)

Closing due to lack of response. Feel free to reopen.