[richfaces-issues] [JBoss JIRA] (RF-12235) Do not overwrite encodeBegin/encodeEnd when extending RendererBase

Lukáš Fryč (JIRA) jira-events at lists.jboss.org
Wed May 9 09:39:17 EDT 2012 

     [ https://issues.jboss.org/browse/RF-12235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukáš Fryč updated RF-12235:
----------------------------

    Description: 
{{cc:implementation}} (resp. {{cdk:body}}) generates {{encodeEnd(...)}} (resp. {{encodeBegin()}} method of renderer.

It overrides the implementation in predecessors of the renderer like [{{RendererBase}}|https://github.com/richfaces/components/blob/develop/common/ui/src/main/java/org/richfaces/renderkit/RendererBase.java].

We can just generate {{doEncodeEnd}} and {{doEncodeBegin}} methods instead of {{decodeEnd}} {{encodeEnd}}, which will allow to do not override methods like {{preEncodeEnd}} which allows to write generic implementation.

There could be detection in place which would detect if predecessor is {{RendererBase}}.

{quote}
{code}
14:55:05 <paul_dijou> I was thinking about having hooks in the renderer
14:55:25 <paul_dijou> Right now, when you use a template.xhtml, it will override encodeBegin and encodeEnd
14:55:32 <bleathem> https://github.com/richfaces/components/blob/develop/common/ui/src/main/java/org/richfaces/renderkit/RendererBase.java
14:55:39 <bleathem> has the hooks doDecode and doEncode
14:55:51 <bleathem> so you can still use the template
14:56:17 <bleathem> and hook into the decoding/encoding
14:56:17 <paul_dijou> Oh good
14:56:39 <paul_dijou> Hmmm
14:56:50 <bleathem> ... if we keep this up, I'll just copy and paste the IRC minutes into the wiki, and we'll have the whole thing documented ;)
14:56:51 <paul_dijou> But if the template override encodeEnd
14:57:00 <paul_dijou> Who will call doEncodeEnd ?
14:57:30 <paul_dijou> +1
14:57:42 <gastaldi> sorry guys
14:57:50 <lfryc> hmm, as Paul says, CDK generates encodeEnd
14:57:51 <bleathem> hmm, does the template generate encodeEnd, or doEndoceEnd?
14:57:57 <paul_dijou> encodeEnd
14:58:02 <bleathem> ah
14:58:11 <bleathem> then we lose the encode hooks
14:58:12 <lfryc> https://gist.github.com/2568559
14:58:19 <bleathem> (we still have the decode hooks)
14:58:37 <paul_dijou> And btw, if no cdk:body in the template
14:58:40 <lfryc> if you don't overwrite cdk:body :-)
14:58:44 <paul_dijou> It will not write encodeStart at all
14:58:53 <paul_dijou> So parent will still write it's encodeStart
14:58:58 <paul_dijou> But no longuer encodeEnd
14:59:04 <lfryc> we could let CDK behave more smart...
14:59:11 <paul_dijou> That was the problem that lfryc solved about icons
14:59:12 <lfryc> it could check the renderer base
14:59:21 <lfryc> and detect if it is RendererBase class
14:59:30 <lfryc> then it would use doDecode, doEncode instead
14:59:52 <bleathem> or, just call out to doDecode, doEncode in it's generated methods
15:00:12 <lfryc> then you couldn't live without RendererBase from RichFaces
15:00:27 <lfryc> I'm having concerns about backward compatibility
15:00:30 <bleathem> well you could, in the same way you could live without CDK templates
{code}
{quote}

  was:
{{cc:implementation}} (resp. {{cdk:body}}) generates {{encodeEnd(...)}} (resp. {{encodeBegin()}} method of renderer.

It overrides the implementation in predecessors of the renderer like [{{RendererBase}}|https://github.com/richfaces/components/blob/develop/common/ui/src/main/java/org/richfaces/renderkit/RendererBase.java].

We can just generate {{doEncodeEnd}} and {{doEncodeBegin}} methods instead of {{decodeEnd}} {{encodeEnd}}, which will allow to do not override methods like {{preEncodeEnd}} which allows to write generic implementation.

There could be detection in place which would detect if predecessor is {{RendererBase}}.

{quote}
4:55:05 <paul_dijou> I was thinking about having hooks in the renderer
14:55:25 <paul_dijou> Right now, when you use a template.xhtml, it will override encodeBegin and encodeEnd
14:55:32 <bleathem> https://github.com/richfaces/components/blob/develop/common/ui/src/main/java/org/richfaces/renderkit/RendererBase.java
14:55:39 <bleathem> has the hooks doDecode and doEncode
14:55:51 <bleathem> so you can still use the template
14:56:17 <bleathem> and hook into the decoding/encoding
14:56:17 <paul_dijou> Oh good
14:56:39 <paul_dijou> Hmmm
14:56:50 <bleathem> ... if we keep this up, I'll just copy and paste the IRC minutes into the wiki, and we'll have the whole thing documented ;)
14:56:51 <paul_dijou> But if the template override encodeEnd
14:57:00 <paul_dijou> Who will call doEncodeEnd ?
14:57:30 <paul_dijou> +1
14:57:42 <gastaldi> sorry guys
14:57:50 <lfryc> hmm, as Paul says, CDK generates encodeEnd
14:57:51 <bleathem> hmm, does the template generate encodeEnd, or doEndoceEnd?
14:57:57 <paul_dijou> encodeEnd
14:58:02 <bleathem> ah
14:58:11 <bleathem> then we lose the encode hooks
14:58:12 <lfryc> https://gist.github.com/2568559
14:58:19 <bleathem> (we still have the decode hooks)
14:58:37 <paul_dijou> And btw, if no cdk:body in the template
14:58:40 <lfryc> if you don't overwrite cdk:body :-)
14:58:44 <paul_dijou> It will not write encodeStart at all
14:58:53 <paul_dijou> So parent will still write it's encodeStart
14:58:58 <paul_dijou> But no longuer encodeEnd
14:59:04 <lfryc> we could let CDK behave more smart...
14:59:11 <paul_dijou> That was the problem that lfryc solved about icons
14:59:12 <lfryc> it could check the renderer base
14:59:21 <lfryc> and detect if it is RendererBase class
14:59:30 <lfryc> then it would use doDecode, doEncode instead
14:59:52 <bleathem> or, just call out to doDecode, doEncode in it's generated methods
15:00:12 <lfryc> then you couldn't live without RendererBase from RichFaces
15:00:27 <lfryc> I'm having concerns about backward compatibility
15:00:30 <bleathem> well you could, in the same way you could live without CDK templates
{quote}


    
> Do not overwrite encodeBegin/encodeEnd when extending RendererBase
> ------------------------------------------------------------------
>
>                 Key: RF-12235
>                 URL: https://issues.jboss.org/browse/RF-12235
>             Project: RichFaces
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: cdk
>    Affects Versions: 4.2.1.Final
>            Reporter: Lukáš Fryč
>
> {{cc:implementation}} (resp. {{cdk:body}}) generates {{encodeEnd(...)}} (resp. {{encodeBegin()}} method of renderer.
> It overrides the implementation in predecessors of the renderer like [{{RendererBase}}|https://github.com/richfaces/components/blob/develop/common/ui/src/main/java/org/richfaces/renderkit/RendererBase.java].
> We can just generate {{doEncodeEnd}} and {{doEncodeBegin}} methods instead of {{decodeEnd}} {{encodeEnd}}, which will allow to do not override methods like {{preEncodeEnd}} which allows to write generic implementation.
> There could be detection in place which would detect if predecessor is {{RendererBase}}.
> {quote}
> {code}
> 14:55:05 <paul_dijou> I was thinking about having hooks in the renderer
> 14:55:25 <paul_dijou> Right now, when you use a template.xhtml, it will override encodeBegin and encodeEnd
> 14:55:32 <bleathem> https://github.com/richfaces/components/blob/develop/common/ui/src/main/java/org/richfaces/renderkit/RendererBase.java
> 14:55:39 <bleathem> has the hooks doDecode and doEncode
> 14:55:51 <bleathem> so you can still use the template
> 14:56:17 <bleathem> and hook into the decoding/encoding
> 14:56:17 <paul_dijou> Oh good
> 14:56:39 <paul_dijou> Hmmm
> 14:56:50 <bleathem> ... if we keep this up, I'll just copy and paste the IRC minutes into the wiki, and we'll have the whole thing documented ;)
> 14:56:51 <paul_dijou> But if the template override encodeEnd
> 14:57:00 <paul_dijou> Who will call doEncodeEnd ?
> 14:57:30 <paul_dijou> +1
> 14:57:42 <gastaldi> sorry guys
> 14:57:50 <lfryc> hmm, as Paul says, CDK generates encodeEnd
> 14:57:51 <bleathem> hmm, does the template generate encodeEnd, or doEndoceEnd?
> 14:57:57 <paul_dijou> encodeEnd
> 14:58:02 <bleathem> ah
> 14:58:11 <bleathem> then we lose the encode hooks
> 14:58:12 <lfryc> https://gist.github.com/2568559
> 14:58:19 <bleathem> (we still have the decode hooks)
> 14:58:37 <paul_dijou> And btw, if no cdk:body in the template
> 14:58:40 <lfryc> if you don't overwrite cdk:body :-)
> 14:58:44 <paul_dijou> It will not write encodeStart at all
> 14:58:53 <paul_dijou> So parent will still write it's encodeStart
> 14:58:58 <paul_dijou> But no longuer encodeEnd
> 14:59:04 <lfryc> we could let CDK behave more smart...
> 14:59:11 <paul_dijou> That was the problem that lfryc solved about icons
> 14:59:12 <lfryc> it could check the renderer base
> 14:59:21 <lfryc> and detect if it is RendererBase class
> 14:59:30 <lfryc> then it would use doDecode, doEncode instead
> 14:59:52 <bleathem> or, just call out to doDecode, doEncode in it's generated methods
> 15:00:12 <lfryc> then you couldn't live without RendererBase from RichFaces
> 15:00:27 <lfryc> I'm having concerns about backward compatibility
> 15:00:30 <bleathem> well you could, in the same way you could live without CDK templates
> {code}
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

More information about the richfaces-issues mailing list