Start using javascript states, deprecate dependent.js

Well, I'm probably going to need dependent.js for CTools too, so I'm not sure just deprecating it is a good idea. They're almost the same code with some slight tweaks.

I guess earl thought that this issue is for 6-3.x

Sorry, I forgot that the D7 javascript code was horribly called 'states', which sounds to me like something else entirely.

In any case, it still matters to me how much recoding is needed, because converting something working to a new system is not a good use of developer time when there are things that still don't work. =)

+1 for replacing with #states

That comment about check_plain() in the patch makes me nervous... shouldn't we fix this in core instead?

Some progress in converting other instances

I think I'm experiencing this problem when changing the Views default numeric filter. I'm currently unable to change the filter to anything other than "is equal to". For instance, if I try to change this to "is less than" or "is greater than", the change is not retained upon clicking "update".

--Ben

Encountered the same thing, just marked #932640: Dependent forms are broken as duplicate.

The current state of states is commited.

There are some places: page display plugin/arguments/some filters which aren't converted totally.

The reason is that there is currently no way to have a input with multiple possible values.
There is a core issue which allows this #735528: FAPI #states: Fix conditionals to allow OR and XOR constructions

Looks like that won't land in core.... Views or CTools maybe?

I thought it would be possible to extend

states.Dependent.comparisons

CTools will continue to support the old-style dependent code (which is nearly the same as the Views code) so where states doesn't work for us, we can use the CTools dependent code.

So i guess this patch should be reverted?

@#13

I guess a regexp could have solved it, too.

I guess using both States and CTools dependent.js is a bit inconsistent.

So, we roll this back, and finally add the dependency to CTools?

EDIT: And the CTools dependency is now present, making it possible to move forward in that direction..

here is the patch which just reverts it.

@TODO

* Require ctools dependency
* throw out views dependency code.

Now it should just work :) The hiding works fine but the form elements aren't shown again.

Interesting, the hiding/showing works as it should for equals & between, but doesn't work right for less than/greater than. Not sure if there's anything special about the less than / greater than fields.

Patch is rolling back the fix to taxonomy autocomplete which is unrelated to states?

#21

Oh yes thanks

This patch now fixes the add-item form.

New version. This time it really works. Perhaps i forgot to cvs diff

Here is the fix for the problem

This time without the dsm

The ctools issue: http://drupal.org/node/958608

This time without the filters

I can confirm that the latest patch now fixes filter radio boxes (for example, the ones for node: nid).
I also tested some field ones (like "Trim"), and it works.

The only thing I noticed is still broken are the argument radio boxes.
Toggling the "Action to take if argument is not present" radios gives me no change.
I'm really tired so the problem might really be between the chair and the keyboard.

Arguments now work as they should.

Thanks for helping and testing this issue.

The committed patch on this issue introduced a bug with exposed numeric filters where no 'value' field appears when the operator select element is <, <=, >, or >=, because the values in the dependency js have htmlentities() applied to them.

Removing the call to htmlentities() fixes the bug. Patch attached.

The same issue in the ctools queue: #958608: Dependendcy does not work with option "<="

Wait, wasn't htmlentities() the fix? :/

@bec

Applying the patch brings up the bug again :( I'm testing with the node: post date filter and node: nid filter.

@dereine -- thanks, I guess I'll pursue this over in #958608: Dependendcy does not work with option "<=" (:

Just a note for anyone following, the ctools issue pointed to a core issue, which now has a RTBC patch: #971120: Radio button values get run through check_plain() twice.
After that lands, we can remove our workaround.

Commited to the 7.x branch.