Here is a sample:
<t:dataList id="myFields"
value="#{FieldConfigurationController.myFields}"
var="entry">
<t:div rendered="#{entry.type=='inputText'}">
<t:inputText id="s_inputText"
value="#{MyController.search.attributes[entry.name]}"
... >
<my:validateCompareTo active="#{entry.contentType=='range' &&
entry.name='to'}"
for="rangeFrom"
operator=">="
.../>
<my:validateEmail active="#{entry.contentType=='email'}" ...>
</t:inputText>
...
</t:div>
<t:div rendered="#{entry.type=='selectOne'}">
...
</t:div>
<t:dataList>
I loop over a list which contains the fields that should be rendered.
These fields are not known at compile time. The fields are created dynamically
based on a database or other repositories.
The model is also completely dynamic. It is represented by maps and accessed by
field names.
The above my:validateCompareTo should only be attached to fields of contentType
range and should validate the upper against with the lower value.
(e.g. see http://myfaces.apache.org/sandbox/validateCompareTo.html
This validator is attached to the bottom-most component to insure that the
foreign component's value has been converted and validated first)
my:validateEmail should be attached to fields of contentType email only.
I don't want to use multiple input fields if they are rendered all the same
way.
Do you now see the difficulty ?
Michael
-----Original Message-----
From: Simon Kitching [mailto:[EMAIL PROTECTED]
Sent: Montag, 22. Oktober 2007 13:43
To: MyFaces Discussion
Cc: Michael Heinen
Subject: RE: optional validator - missing rendered attribute
---- Michael Heinen <[EMAIL PROTECTED]> schrieb:
> A simple example is the dynamic rendering of range input fields.
> A validator should be added only to the second field (e.g. dateTo or a
> max size) which validates the lower value and the upper value.
Sorry, I don't understand that at all.
> Or some input fields could be of type email and should be validated
> accordingly but be rendered like other fields.
A component representing an email field should have an EmailValidator attached
to it, and a component representing something else will not have a validator
attached to it. Isn't that completely static information that is known to the
page author? Where does "active" come into that?
> So there following alternatives:
> - use component bindings and add the validators dynamically
> - use separate input fields with rendered checks (one with validator and
> one without which is ugly)
Why would a field sometimes be an email input field and sometimes not?
A property in the model (ie the setter method that the value attribute's EL
value-expression refers to) will hold either an email or not, won't it?
And the EL expression is fixed and refers to just one property, yes?
So why isn't it possible to simply define in the page which type of validator
is attached to the component?
Regards,
Simon
