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

Lukáš Fryč (JIRA) jira-events at lists.jboss.org
Mon May 28 14:22:18 EDT 2012


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

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

    Assignee: Lukáš Fryč

    
> 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č
>            Assignee: Lukáš Fryč
>             Fix For: 4.3.0.Milestone1
>
>
> {{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