so some proxy drawbacks of the old approach are solved.
what changes for the user:
you just have to check the compatibility with your component lib.
old:
requirement of the cglib approach:
component and converter creation via the jsf application.
new:
requirement of the new approach:
all input components have to call the method getConvertedValue.
(a method of javax.faces.render.Renderer)
you just have to check the compatibility with your component lib.
old:
requirement of the cglib approach:
component and converter creation via the jsf application.
new:
requirement of the new approach:
all input components have to call the method getConvertedValue.
(a method of javax.faces.render.Renderer)
what's the workaround, if a component lib doesn't do that so far?
it's still possible to use the cglib approach or the adapter fallback approach of the alternative module.
it's still possible to use the cglib approach or the adapter fallback approach of the alternative module.
how do i reactivate the cglib approach?
just add myfaces-extval-alternative-1.x.x-SNAPSHOT.jar to the classpath.
that's it!
just add myfaces-extval-alternative-1.x.x-SNAPSHOT.jar to the classpath.
that's it!
