Tv's Input Option Values Leftovers

When setting up a TV we can fill in an input option values as inline content, options separated by `||` , by bindings, delimiters and so...
The problem is when for example we save the TV with some chosen option across the different resources when adding/editing them,
And afterwards when we want to edit the TV’s input option values, and remove an option that we used already somewhere in our resources,
Then it would show this removed-option at those resources even that we removed it from being an option, it would still be there but as a *blank label.

So generally speaking it doesn’t update the input option values. and we left with a *blank leftovers.
It’s because when rendering the values for the TV’s in the Back-end Resource Page it takes the values of the TV’s from `[[+PREFIX]]site_tmplvar_contentvalues` Table, and this values isn’t always fit to what we set(changed) to be the options of the particular TV.

I Think that it would be much better if while rendering the tv input in the manager, to cross-check if the stored values are those who appears as part of the `Input Option Values` so if we change our input option values/or deleting a resource/chunk/whatever-filled as an option, you don’t need to go and update the tv all across your site to avoid those ugly blanks.

I suppose it’s a known behavior (if so, then why?), or is it a bug?


A little note: * Blanks appear when using check boxes, In other types (e.g. `DropDown List Menu`) it’s just outputs on the front-end the option we saved and removed.
_
This issue poped as part of the discussion at the following topic (sortableCheckbox input filter):
http://modxcms.com/forums/index.php/topic,57045.msg339370.html#msg339370
_
Filed here: http://bugs.modx.com/issues/3494

It’s hard to know how to handle this. The value is actually saved in the database as the value for that resource. MODx doesn’t want to be changing or ignoring existing TV values for resources behind the scenes. Limiting user input to exclude values that are already in the DB is always going to cause some problems, IMO.

One solution is to plan your input option values so they don’t have to be changed. Another would be to write a utility snippet that would change the old values for you. If you’re deleting existing input option values often, you should probably reevaluate your design strategy.

(Just my $.02).

Quote from: BobRay at Jan 12, 2011, 04:39 PM

It’s hard to know how to handle this. The value is actually saved in the database as the value for that resource. MODx doesn’t want to be changing or ignoring existing TV values for resources behind the scenes. Limiting user input to exclude values that are already in the DB is always going to cause some problems, IMO.

One solution is to plan your input option values so they don’t have to be changed. Another would be to write a utility snippet that would change the old values for you. If you’re deleting existing input option values often, you should probably reevaluate your design strategy.

Allow me to disagree, for example, if you’re using it with chunks (pretty common, right?) or @SELECT binding which also makes a lot of sense, your going to face some old tv-content on some point, then you’ll need to update this tv all across your site.
It makes lots of sense to me that if you set options, the content of the tv has to be one of those options (at least have the ability to check it) and in case it isn’t fall back to the default value.

Maybe making an option to allow setting it to behave as `store & use static values` / `check & update dynamicly values`
on TV-Input-UI at the manager when creating/editing would be great.

I assume it’s really just to process the chunks/@selcet/whatever again from the input-options ,explode them, retrieve the static stored tv value/s (explode them too maybe) and compare them, if they differ and doesn’t mach any of the options then set them to fall back to the default value. just an assumption that it is the way to do so.

Personally, I lack the technical knowledge to do it.
But also i think it should be trivial functionality, yet again, maybe i’m wrong of my understandings.

I see what you’re getting at. This sounds like a good candidate for something like the Evo DocManager module, where you can make changes on a list of resources.

Quote from: sottwell at Jan 15, 2011, 07:52 AM

I see what you’re getting at. This sounds like a good candidate for something like the Evo DocManager module, where you can make changes on a list of resources.

I don’t talking about getting a new module/cmp for this, in revo we do have the batcher.
but i mean just to have the trivial functionality of cross-checking your vary of input-options with the stored values to be sure they still relevant.

for now i’m just troubled with the sortableCheckbox because of this issue.
but it affects all kind of tvs/inputs.

What would you want MODx to do when a current TV value doesn’t match one of the current input option values?

Would you settle for a utility that would just list the resources with improper TV values?