You may know by now that with the release of version 10 of the platform, ATG supports storing String values to the database.
Here’s an example of the standard way enumerated properties have been configured up until now:
<property name="productType" data-type="enumerated"> <attribute name="useCodeForValue" value="false"/> <option value="pants" code="1"/> <option value="shirt" code="2"/> <option value="shoes" code="3"/> </property `
The “code” attribute value is what’s stored in the database, and the “value” attribute value is the String value used within the application.
But now, you can persist Strings instead of integer values to the database for your enumerated properties. I’ve outlined two ways to do this below.
The Officially Sanctioned (read documented) Way…It is Written…
This is what you’ll find in ATG’s documentation starting with release 10. It looks something like this within the Repository definition:
<property name="productType" data-type="enumerated string" > <attribute name="stringEnumProvider" value="/mysite/repository/ProductTypeProvider"/> </property> `
The nested attribute above should reference a component (that you’ll need to create) that does the following:
a) Implements atg.adapter.gsa.StringEnumProvider
b) Overrides getCodes() — Returns the list of values to be persisted to the database
c) Overrides getResources() — Returns the list of values to be displayed to users of applications like Merchandising.
This option is actually really nice. You can read the enumerated values from a database, or a resource bundle — pretty much anything you can think of since the implementation is up to you.
An Undocumented Alternative
This would be the “what you don’t know” part. I recently stumbled across an undocumented class that can be used to accomplish in some cases what you might use the documented option for. An example configuration looks like this:
<property name="productType" data-type="enumerated" property-type="atg.adapter.gsa.StringEnumPropertyDescriptor"> <attribute name="useCodeForValue" value="false"/> <option value="pants" code="pants"/> <option value="shirts" code="shirt"/> <option value="shoes" code="shoes"/> </property> `
The key things to notice here are these:
a) We use a custom property-type of atg.adapter.gsa.StringEnumPropertyDescriptor.
b) The “code” attribute of each value is what is stored in the database.
It’s much quicker to use this particular approach — less code and configuration. Although, it’s admittedly less flexible.
It’s actually surprising it took ATG this long to provide support for Strings with enum values and codes. Most DBAs I’ve worked with would much rather store data that is self descriptive when it is relevant to the domain of the system and business. For example, persisting a value of “1” into a “product_type” field is virtually meaningless outside of the context of the Repository definition file that defines what “1” means. On the other hand, if we insert “SHIRT” into that same field, the meaning becomes patently obvious independent of any application that may access that data.