myfaces-extval meets myfaces-trinidad

yesterday i added a much better trinidad support.

all parts of the trinidad support are available within an own module.

to enable the trinidad support you just have to add
myfaces-extval-trinidad-support-1.*.jar
to the classpath.

it provides e.g. client-side validation. this means that client-side trinidad validation gets based on annotations (the simple extval annotations and jpa annotations). it's also possible to use client-side validation based on custom annotations. moreover, this approach allows to reuse implementations of existing client-side trinidad validators.

the trinidad support shows how extval is able to use client-side validation features of component libs in a very easy way.

myfaces-extval got independent of cglib

some days ago i introduced a new mechanism which replaces the cglib approach.
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)

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.

how do i reactivate the cglib approach?
just add myfaces-extval-alternative-1.x.x-SNAPSHOT.jar to the classpath.
that's it!