Enum: Label returned instead of value

Problems and solutions
1

Following situation:

page-type with the following property:

property name="filterAttributes" type="string" dbtype="varchar" maxLength=500 required=false enum="artikelAttribute" control="enumSelect";

In the database the enum value is stored correctly as a value list.

I have a corresponding view for the page-type having this:

<cfparam name="args.filterCategories"	type="string"	field="produktliste.filterAttributes"	editable="false" />

In Preside 10.16 the value of args.filterCategories is the value of the enum.

In Preside 10.23 the value of args.filterCategories is the label of the enum value.

Annotation: The fact, that the previous version was quite old doesn’t matter here. In some version later than 10.16. this change happen.

This change is really a big one and doesn’t make sense at all! In my case I’m using the value for checkboxes. This is breaking the code completely, because there’s no way to get the value of the label.

What happened here? And what was the intention? Is it just a bug?? I consider filing this as bug.

2

I expect this is related to changes to the ENUM renderer. With the param defined as it is, you are requesting that the view system should render the values using whatever renderer there is for the field.

To guarantee getting the raw value, you should do:

<cfparam name="args.filterCategories" type="string" field="..." renderer="none" />

(from top of my head, but fairly certain renderer="none" is the one)

3

Yes, I think it’s this one: [PRESIDECMS-2310] - JIRA

But seriously, THIS one is a groundbreaking change that is breaking a lot of code!!
This means we absolutely need to check every ticket in future versions in our applications.

This also means, that I will stick to my build process including the preside code in my repo and don’t pull the latest automatically. I don’t want to think about what would happen if I need to restart a docker container which pulls automatically a version that breaks something like this.

4

And beside this: This change of the renderer makes absolutely no sense in my opinion. Having a helper function is really nice, but applying this automatically brings more trouble than solutions.

5

As a side note, you should ALWAYS be explicitly specifying the Preside version in your app and/or build process.

6

I would argue that the code is only working accidentally in the first place. The preside object view param system is there explitly to help you get values from the database, rendering when a renderer is available. I you want raw values, you have always been able to explicitly say so and should always do so.

Yes, you absolutely have to check all the release notes for our “minor” release versions (i.e. 10.18.0, 10.19.0, etc.). If this was a change in a hotfix, I’d be inclined to agree with you but our minor releases will make new features and minor changes such as this one.