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.
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.
-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
>
>