@SHALE-442

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

Am Dienstag, 1. April 2008 schrieb Torsten Krah:
> WARNING: bad headers - Duplicate header field: "Reply-To"

Something off-topic, i'll wrote the mail 3 times now and 2 got not delivered
because the list produces invalid mail headers (it inserts a reply-to header
instead of replacing the existing one, in the end the mail gots 2 of them
which is not valid).


http://shale.apache.org/mail-lists.html does not tell me whos responsible and
where should i mail this problem to, can anyone help?

Torsten

[Greg Reddin-4]

We got the mail three times - at least I did :-)

On Tue, Apr 1, 2008 at 1:37 AM, Torsten Krah
<tkrah@...> wrote:
>  Something off-topic, i'll wrote the mail 3 times now and 2 got not delivered
>  because the list produces invalid mail headers (it inserts a reply-to header
>  instead of replacing the existing one, in the end the mail gots 2 of them
>  which is not valid).

As for that specific problem I have no idea what to do about it. Sorry.

>  http://shale.apache.org/mail-lists.html does not tell me whos responsible and
>  where should i mail this problem to, can anyone help?

You can try dev-owner@..., but I'm not sure who that will
go to. Hopefully somebody else on this list will know how to address
your problem. I'm glad you didn't just machine gun the send button
though :-)

Greg

[Gary%20VanMatre]

>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

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