Defining complex validations for flex items

Question

Hi,
We've defined a flex regions and a number of flex items. We would like to define more complex validation logic at the entity object level, whereby we'd like to reference both 'fixed' entity attribute values as well as values of the flex items.
Could you please indicate how this can be achieved in the validateEntity method of the EntityImpl.java class.
We know beforehand which flex items will be displayed based on the value of one of the fixed entity attributes (e.g. if the attribute request_type='assist' then display flex items A and B, if request_type='info' then display flex items D, E and F). We use flex items because the number of request_types and corresponding 'dynamic' attributes is too large (and subject to frequent additions, deletions or modifications) to incorporate in a fixed static db table structure.
If you can suggest alternatives to using JHeadstart flex items, these are more than welcome, of course.
Many thanks beforehand,
Ibrahim

Answer 1

Dear Steven,
First of all many many thanks for your prompt reply. We can use JSF EL expressions to conditionally render flex items. I'd like to illustrate my question with a simple example:
We have three fixed entity attributes displayed:
RequestType
Birthday
Sex
and two flex items (rendered at runtime for a specific runtime value of RequestType):
Smoker (Y/N)
Weight
Before saving the record I'd like to check a number of validation business rules that depend on the fixed entity attributes as well as the two flex items being displayed.
Consequently, I'd need to be able to access the flex item values provided by the user, inside my validateEntity method (right ?).
I can define simple validations for the flex items, but I can only access the flex item value and possibly the DependsOnItemValue.
PS: When I define a flex item of type 'inputtext' and try to access its value using a bind variable in the validation query of the flex item e.g.
:ItemValue = 'blabla'
Suppose the user fills in the value Abracadabra, the validation logic substitutes as follows:
Abracadabra = 'blabla' (which generates an Oracle error). I'd expect the following substitution to take place:
'Abracadabra' = 'blabla'