Well, the problem with JSF converters is that there's no way to do dependency injection on them. So it'd be very difficult to assign a delegate to them. I also don't see anything wrong with tight coupling in this case. It's unlikely that you'll want to change the conversion rules dynamically by changing delegates instead of just changing the converter used.
On 12/2/05, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]> wrote: > Instead of subclassing it, I would "prefer" to delegate, that creates > two classes with a less tight coupling. > > -----Original Message----- > There's not much in a converter and there shouldn't be any reason why > you couldn't do this. > However, since you're having to pass in a FacesContext and a > UIComponent, I think you'd have to reimplement a lot of unnecesary > support classes. > > I'm not sure I'd stick it in a static utility method, but maybe that > makes sense in your use cases. > > I'd probably go with a presentation-layer-independent converter class. > Then subclass it to create the JSF converter. > > > When I look at my own JSF converters, this is a trivial refactoring. > I've already got the non-JSF conversions being handled in separate > methods which are called by the getAs methods. > > On 11/30/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > Has anyone ever used a JSF converter in code that wasn't specifically > > related to JSF? The reason why I am asking is that we are migrating > > an application to JSF and a portion of the pages are in JSF but a > > portion are still in Struts. > > > > Two possible ideas come to mind: > > > > 1.) Use the converter's getAsString method inside of a static utility > method > > > > 2.) Move the logic from the getAsString method to a static utility > method. > > > > I suppose approach #2 is less of a hack since you avoid FacesContext > > and other JSF specific stuff in your static helper. > > > > Any other thoughts or approaches? > > > > TIA, > > > > sean > > >
