Hi Michael,
---- Michael Heinen <[EMAIL PROTECTED]> schrieb:
> 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 ?
Yes, I see.
However I think this is a fairly unusual situation. I don't believe that
handling validation for such dynamically-created and dynamically-typed input
components really qualifies as "a common use-case".
However can't this be solved simply by moving the input component inside the
type-test? IE rather than:
for each field to render
add an inputText, always rendered
attach validator1, active if type=1
attach validator2, active if type=2
do:
for each field to render
add inputText rendered if type=1, with validator1
add inputText rendered if type=2, with validator2
Yes, this does mean repeating the input-component for each type. But that gives
the opportunity to change the actual input component type based on what the
field-type is. Ok, *you* might happen to always want an input-text for all
types, but I think this is a more general solution, and not too inconvenient in
your case.
In terms of memory usage and performance, the above are about equal. Either one
component exists, with N validators (N+1 objects), or N components exist each
with 1 validator (2N objects). Given that N is fairly small, this isn't
significant IMO.
That doesn't mean there is anything wrong with your "active" solution, but I
don't personally see any need to amend the spec to support this use-case when
it is (a) pretty rare, and (b) already has a reasonable solution. That's just
my view of course.
By the way, open-source projects are always happy to get suggestions/feedback
(or should be); it's how projects get better. However when posting a message,
please take care not to imply that the people in charge of the projects are
fools for not solving the problem the way you think it should be solved. This
email thread was perhaps a bit more confrontational than necessary..
Regards,
Simon
