myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Heinen" <...@recommind.com>
Subject RE: optional validator - missing rendered attribute
Date Mon, 22 Oct 2007 15:18:44 GMT
Hi Simon,

maybe I did not express myself or the problem well. 
I didn't want to go on confrontation course, sorry if you got that impression.
Quite the contrary I am happy about feedback, workarounds and suggestions. That's the reason
for my postings.

I just was astonished that all components have the rendered attribute but validators not.
Now I know that there is not any existing feature that I missed and use various input components
with their own validators.

But a disadvantage of this is from my point of view that I have also to use multiple label
tags (or EL expressions for the for-attribute because I have then various input fields with
other client ids used in the for-attribute of the label tag).
And ajax updates will be a little bit more complex because I have to update a container tag
rather than directly a field.

Michael


-----Original Message-----
From: Simon Kitching [mailto:simon.kitching@chello.at] 
Sent: Montag, 22. Oktober 2007 16:08
To: MyFaces Discussion
Cc: Michael Heinen
Subject: RE: optional validator - missing rendered attribute

Hi Michael,

---- Michael Heinen <mhn@recommind.com> 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

Mime
View raw message