dev@javaserverfaces.java.net

Re: JSF-RI disallows custom String (and Object) converters?

From: Adam Winer <adam.winer_at_oracle.com>
Date: Tue, 09 Aug 2005 11:05:37 -0700

Mike Kienenberger wrote:
> I'm not suggesting registering a new converter type, only returning a converter.
> But this is arguing about one possible implementation, not about the
> design in general.
>
> There are ways to get around performance issues.
>
> If it takes a custom isThereAStringConverterRegistered() method in
> com.sun.faces.application.ApplicationImp, caching whether a String
> converter is registered, so be it.

No, jsf-api cannot depend on jsf-ri code.

> if (converterType == String.class &&
> !application.isStringConverterRegistered()) { return null } can be
> performant.
>
> Supporting String converters will greatly reduce vast amounts of
> redundant empty-string-checking code. The JSF-RI (and thus the JSF
> spec) shouldn't sneakily toss out the possiblity deep in some private
> method just because it's hard to implement.

What you're asking for requires a spec change. We
can take it up in JSF 2.0.

-- Adam



> -Mike
>
> On 8/9/05, Adam Winer <adam.winer_at_oracle.com> wrote:
>> Mike Kienenberger wrote:
>>> Performance seems like a pretty weak argument.
>> Um, but in this case it's a real argument. I've seen
>> profiles where Converter creation was very, very painful,
>> and that's in cases where a Converter was successfully
>> returned. Exceptions are totally brutal to create.
>>
>> But a plain fact is that it would require a spec change
>> to support what you're asking for: the spec is explicit
>> about what by-type converters are registered by default.
>>
>> -- Adam
>>
>>
>>
>>> If that's the only issue, then one of many possible solutions is to
>>> return some default placeholder converters for String and Object that
>>> just pass-through the values when no converter is found.
>>>
>>> -Mike
>>>
>>> On 8/9/05, Adam Winer <adam.winer_at_oracle.com> wrote:
>>>> Mike,
>>>>
>>>> You can create a custom converter and manually attach
>>>> it to components, but we can't really allow custom
>>>> String and Object converters.
>>>>
>>>> For starters, Application.createConverter(Class) throws
>>>> an exception if nothing is registered - so we'd have
>>>> to wrap UIInput.getConverterWithType() with
>>>> "try/catch (FacesException e)" - which would be
>>>> brutal for performance, since a common scenario would
>>>> result in a thrown exception.
>>>>
>>>> -- Adam
>>>>
>>>>
>>>>
>>>> Mike Kienenberger wrote:
>>>>> I notice that the JSF-RI disallows custom String (and Object) converters.
>>>>>
>>>>> Inside the private method UIInput.getConverterWithType(FacesContext context),
>>>>>
>>>>> // if converterType is null, String, or Object, assume no
>>>>> conversion is needed
>>>>>
>>>>> I don't see anything mentioned in the spec or javadocs that requires
>>>>> this restriction.
>>>>>
>>>>> Does this limitation have to followed in all JSF-compliant
>>>>> implementations? (I originally brought this up on the MyFaces dev
>>>>> list, but was told that Myfaces had to follow the JSF-RI behavior for
>>>>> compatibility.)
>>>>>
>>>>> My use case is that I would like to create a java.lang.String
>>>>> converter that automatically converts all empty strings to null.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> -Mike Kienenberger
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>