Hi.
I want to fix this bug 442 and want to ask some question here about doing
that, if thats ok, i'll hope so.
I'll fixed the decorator not to apply shales validator renderer if the
renderer family matches the ajax stuff, which let them work again.
However this seams not the ultimate approach to me because there are so many
different familys and renderers which should not be decorated, that i'll have
to code everytime they change.
Are there any suggestions or ideas (already) how this should be done
the right way?
I have struggled with this issue and do not see a clean/easy fix. Most rich
validators are bundled with component libraries that have a unique rendering
strategy for script. In the case of shale's common validator, the script needs
to be built in the context of rendering. This is important for children of the
UIData component family. Unfortunately, there is not yet a generic way to
extend a renderer without knowledge of the component library. This issue
surfaces with Tomahawks Ajax renderer interface contract.
However, I believe that JSF 2.0 will provide listeners that can be attached to
components and fired at render time but we'll have to wait and see if that can
be used to build rich validators that are not coupled to a single component
library.
Or, maybe bytecode injection would be the ticket? I guess we could take some
studies of tapestry 5? Maybe inject our own listeners :-)
Torsten
Gary---BeginMessage---
Hi.
I want to fix this bug 442 and want to ask some question here about doing
that, if thats ok, i'll hope so.
I'll fixed the decorator not to apply shales validator renderer if the
renderer family matches the ajax stuff, which let them work again.
However this seams not the ultimate approach to me because there are so many
different familys and renderers which should not be decorated, that i'll have
to code everytime they change.
Are there any suggestions or ideas (already) how this should be done
the right way?
Torsten
smime.p7s
Description: S/MIME cryptographic signature
---End Message---
