Please state differences from conditional_fields & Hierarchical Select Node Reference modules

Hello

There are significant differences between the modules, despite a similarity in the name and the nature of the field relationships - (controller and controlled)

From Conditional Fields description:

Conditional Fields allows you to assign CCK fields with allowed values as ‘controlling fields’ for other fields and groups. When a field or group is ‘controlled’, it will only be available for editing and displayed if the selected values of the controlling field match the ‘trigger values’ assigned to it.

When editing a node, the controlled fields are dynamically shown and hidden with JavaScript.

So, conditional fields only handles the display of the controlled fields but the actual values and options remain unchanged when shown / hidden.

This module instead does not hide or show fields, instead when the controlling field is changed on the form it triggers an AHAH refresh of the controlled field(s), and then the value or options (in a select field for instance) can change depending on the selected value of the controller field.

A use case could be for a music site with three content types - Artist, Album and Track. An Album contains a nodereference field for Artist, and a Track contains a nodereference field for Artist and Album. When adding a track, first you pick the Artist and then this module, via AHAH, updates the Album list to only contain the Albums from the selected artist rather than from all artists.

Currently I don't plan to have the ability to show or hide fields, but it would actually be quite trivial I believe to add this, perhaps via some hooks that I intend to set up to allow developers more scope.

The big difference in this module's approach is that the heavy lifting is done in drupal itself using the forms api (via AHAH of course) where as, I believe, conditional fields does much of it on the client side via javascript.

Infact I don't expect this module to contain any additional javascript files at all, just a couple of json callbacks.

I've now added the use case to the project page and added a link here for those interested in the differences - so thanks for asking for the clarification.

Regarding Features integration, that is pretty high on my list too and so I will ensure that it does provide all the dependent field settings ready for export.

Sounds similar in functionality to what I wrote up with Option Trim but as with the other module mentioned in this issue, my approach was javascript heavy where I'm thinking your AHAH approach has the potential to be cleaner. Might be useful for you to look at the features/obstacles there anyhow.

The nice thing about this module (hopefully) vs something like Option Trim is that it's general and can be used for other cases. For instance, we have a node type "Daily Report" which has a noderef to an "Employee", a number field for hours worked, and a number field for wage. The wage needs to be overrideable, but have a default per-employee. Ideally, using this module, I can auto-populate the wage field once "Employee" noderef is populated, based on the default wage set on the "Employee" node.

From reading module descriptions looks like you may want to compare with Hierarchical Select + Hierarchical Select Node Reference modules

I'd not seen Option Trim before, i will take a look thanks.

About Hierarchical Select Node Reference, there are a few differences:

Hierarchical Select Node Reference is limited to controlling one field, so in my use case above for the artist / album / track, I believe you would only be able to store either the album or the artist.

This module instead lets you work with multiple fields and multiple levels of hierarchy so you can store both the artist and album inside the track content type.

Also, another benefit is you will be able to pick and choose widgets, say you have thousands of artists you can use an autocomplete widget first, then the next level can use select boxes, or even check boxes.

Finally, this module won't just be for node references, it will work with normal cck fields too, and as obrienmd suggests will also allow some customization of how fields react after the AHAH has been triggered.

The module is around 75% complete now, and i'm hoping to commit within a couple of days.

I've been looking for this module for a while. I've been using Hierarchichal Select to overcome this need in a couple of projects so far. For sure I will be one of the very first users.

I have now made the initial commit for this module. Its in a working state, but there will likely be bugs so please don't use on a live site.

The dev release should be auto-created in a few hours.

I aim to follow up with some documentation later this week, as currently the README is quite sparse.

http://drupalcode.org/viewvc/drupal/contributions/modules/dependent_fiel...

Looking forward to testing this!

I am using this module.But when I want to use this for multiple checkboxes/select list then the following warning is showing:

* warning: Illegal offset type in isset or empty in C:\wamp\www\mysite\sites\all\modules\dependent_fields\includes\form_elements.inc on line 129.
* warning: Invalid argument supplied for foreach() in C:\wamp\www\mysite\sites\all\modules\dependent_fields\fields\text.inc on line 93.

Is there any solution for that?

@alamin328

Your problem should be in its own issue, as this is just about the conceptual differences and similarities between other modules.

I tested option trim and is very very more fast than dependent fields;and does all that dependent does;
so think javascript is better solutions for manage hierarchy terms;

problems is that there isn't support for the views, but this problem is also for dependent;
is difficulty to create views inetgration for modules? some good example ?

@alb

This question should be in its own issue, in the queue of the module you are discussing. If you want to ask about a feature for options trim, then I suggest you ask there.

Regarding doing things the OptionTrim way, client side javascript is always going to be quicker than AHAH or AJAX, there are pros and cons with both approaches.

but for dependant module is there a solutions for to create an integration with views? is there good example for analyze the code (used in similar modules?)

Doing some cleanup as there's a new version for D8/9 and D6 is no longer alive