I think the documentation could be improved on the topic of validation.
The PDF manual contain lots of references to the word ‘validation’, but the only major section devoted to field validation that I could find were three pages on field validation in the Implementation guide, which runs through the user interface for setting up a simple validation in Workbench, but does not help determine what can and cannot be done. Pressing F1 while using the Field Validation dialog displays more of the same, but you can click through to a page entitled “Default Validations and their Parameters.” However, this merely lists the available Validation Types, which are pretty self-explanatory. For example, it does not explain that in JEXL validation you have to use the $value to access the value entered into the field, and that this variable is a string even if the field’s datatype is, say, integer. It doesn’t even begin the document what all the extensions available in Extension validation are for. And the coverage of item validation is even worse.
What is needed is documentation on what can and cannot be tested using the different Validation Types. For example, at present the information given in this forum post is missing from the manuals. At least two people (the person to whom this post is replying, and now me) have wasted a lot of time trying to get something to work that either should not be an option in the user interface, or we should have been warned about by the documentation. If as I suspect (but have yet to have confirmed) this means the value entered into the field cannot be used in a Conditional validation type rule, then this is important information we need to know up front, before we waste days fishing around for a solution.
I stumbled on this post while looking for an explanation of JEXL validation, and I want to second what Andrew is saying here. The instance he mentions is just one of many like that. It would make a big difference in how I feel about using Rhythmyx if the documentation were more thorough, and also more accessible. Not only is it missing information, but I have to search through twelve or so Adobe documents to discover that the information I need isn’t there. That is discouraging.
If you look at my profile, I have many questions on this forum. And I always hunt the documentation first before I post to the forum. I search the documentation, FastForward, and the forum before posting. And maybe half the things I ask about seem like they are things that ought to be documented, things like what types of variables you are allowed to put into a workflow notification.
[QUOTE=Andrew Morrison;4219]I think the documentation could be improved on the topic of validation.
The PDF manual contain lots of references to the word ‘validation’, but the only major section devoted to field validation that I could find were three pages on field validation in the Implementation guide, which runs through the user interface for setting up a simple validation in Workbench, but does not help determine what can and cannot be done. Pressing F1 while using the Field Validation dialog displays more of the same, but you can click through to a page entitled “Default Validations and their Parameters.” However, this merely lists the available Validation Types, which are pretty self-explanatory. For example, it does not explain that in JEXL validation you have to use the $value to access the value entered into the field, and that this variable is a string even if the field’s datatype is, say, integer. It doesn’t even begin the document what all the extensions available in Extension validation are for. And the coverage of item validation is even worse.
What is needed is documentation on what can and cannot be tested using the different Validation Types. For example, at present the information given in this forum post is missing from the manuals. At least two people (the person to whom this post is replying, and now me) have wasted a lot of time trying to get something to work that either should not be an option in the user interface, or we should have been warned about by the documentation. If as I suspect (but have yet to have confirmed) this means the value entered into the field cannot be used in a Conditional validation type rule, then this is important information we need to know up front, before we waste days fishing around for a solution.