Onchange element JS not disabling or 'readonlying' data elements

[rrwilson]

Hi there,

I just noticed that when the target is a date element it doesn't let you stop the user from playing with it. It works nicely with other fields, but not with that.

RW.

 

[cheesegrits]

Yeah, not all elements respond to all the available actions. In the case of the date element, it's because the date element is actually multiple input fields of different types.

You could probably work round it by coding it by hand in the JS box. For one of my test dates called 'slash_date', this ...

jQuery('#date_test___slash_date_cal').prop('readonly', true)
jQuery('#date_test___slash_date_cal_cal_img').prop('disabled', true)

Note the suffixes to the element name (_cal and _cal_cal_img) to get the IDs of the constituent parts.

If you use the time widget, you'd need to do something similar to disable that.

To enable, use false instead of true.

What really needs to happen is that the code which does the FX needs to be moved out of the form JS, and i to the element JS, so each element type knows how to do a given effect to itself. That didn't happen originally because to start with we only had variations on show/hide (slide in/out, fade in/out, etc) as the FX, which always happen on the element container div, not the inputs themselves, so the same code worked for all types. It's only recently we've added disable and readonly, which need to "know" what HTML form inputs a given element is made up of. I added some basic testing, so it knows if it's a simple field or a SELECT, but that only goes so far.

But that's more work than can happen on subscription support, it'd have to be something that one or more people contributed some $$ to.

-- hugh

 

[rrwilson]

Thanks Hugh, I think that's one for the morning... late here and head fried.. :|

 

[cheesegrits]

Monday morning here. Head still fried.

-- hugh