Craig, I think we're talking about two slightly different things. I'm talking about creating a JSF Converter as a subclass of some kind of generic converter. You'd use the generic converter outside of JSF and the JSF converter inside JSF. That way, you don't need to mock up a FacesContext or UIComponent.
I still don't see how you can use dependency injection on a JSF converter inside a JSF application. What am I missing? I've got a managed bean (database-backed data source) that I'd love to inject into my converters. Currently I have to ask JSF for the bean by name inside my converter code..... On 12/2/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > On 12/2/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > > 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. > > Why not? If the converter implementations have a public zero-args > constructor, you could use a DI framework to create them, and configure > their properties appropriately. > > > 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. > > The hard part for this use case is that the method parameters of the actual > conversion calls take a FacesContext and a UIComponent, so you'd have to > mock that sort of stuff up somehow if it's really a non-JSF use case. > > Craig > >
