Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Message-ID: <1215148948.1128370668726.JavaMail.jira@ajax.apache.org>
Date: Mon, 3 Oct 2005 22:17:48 +0200 (CEST)
From: "Adam Winer (JIRA)" <myfaces-dev@incubator.apache.org>
To: dev@myfaces.apache.org
Subject: [jira] Commented: (MYFACES-659) Most components 'overuse' encodeEnd
In-Reply-To: <1186705527.1128333109765.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/MYFACES-659?page=comments#action_12331217 ] 

Adam Winer commented on MYFACES-659:
------------------------------------

FYI, encodeBegin()/encodeChildren()/encodeEnd() only exist as separate methods to support JSPs.  If the EG had it to do over again, we would likely only have a single encodeAll() method (which would have been perfectly sufficient in the JSF 1.2 API).  Putting everything in encodeAll() is fine by me...

> Most components 'overuse' encodeEnd
> -----------------------------------
>
>          Key: MYFACES-659
>          URL: http://issues.apache.org/jira/browse/MYFACES-659
>      Project: MyFaces
>         Type: Improvement
>   Components: Implementation
>     Versions: 1.1.0
>     Reporter: Thomas Timbul

>
> Most of the component rendering implementations make use only of the encodeEnd method.
> If this is the case, why do encodeBegin and encodeChildren exist in the first place?
> I believe that encodeBegin should be used to validate parameters and children prerequisites, prepare the component for rendering (e.g computing a model or something), and rendering the start tag(s), encodeChildren should take care of any child components (i.e. the actual body) and encodeEnd should finish off by closing the tags opened in encodeBegin.
> Yes, this will create an overhead for sharing data between the methods, but it would make the operations clearer (intutitive method names?)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira