I'd say leave it in UIXComponentBase.
Kamran Kashanian wrote:
Currently UIXComponent is a pure abstract class and does not have
*any* implementation in it (except for a set of static methods which
were recently added).
Should I:
1) Move the implementation for "getContainerClientId(FacesContext
context, UIComponent child)" up to UIXComponent and break the
convention used so far.
2) Leave the implementation in UIXComponentBase.
Please respond if you care.
On Mon, Mar 10, 2008 at 12:51 PM, Kamran Kashanian
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Scott,
I don't have a problem with moving the default implementation for
"getContainerClientId(FacesContext context, UIComponent child)" up
into UIXComponent and making it concrete (not abstract).
I am not sure what the original rationale was for keeping
implementation out of UIXComponent. Looking at the RI code, looks
like UIComponent is abstract and *does* include default
implemetation for all of the 1.2 APIs.
On Mon, Mar 10, 2008 at 11:38 AM, Scott O'Bryan (JIRA)
<dev@myfaces.apache.org <mailto:dev@myfaces.apache.org>> wrote:
[
https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577083#action_12577083
<https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577083#action_12577083>
]
Scott O'Bryan commented on TRINIDAD-961:
----------------------------------------
I'm not sure I agree with this patch. This change involves
adding an abstract method to UIXComponent and assumes that
everyone making custom components is going to extend
UIXComponentBase. This is not something that is enforced by
either the contract OR the api.
Since UIXComponent is already an abstract class (and not an
interface), I think the default implementation of this new
method needs to be on UIXComponent so that custom component
code continues to work. I know the convention in UIXComponent
has been that this class is totally abstract, but I can't help
but think that the reason for making this an abstract class
rather then an interface was so that we did NOT run into these
types of issues as new methods were added.
What I'm basically proposing is instead of making the new
method and abstract method, that we provide a simple default
implementation so that any code extending this class would
"just work" between 1.2.6 and 1.2.7..
> NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER
> -------------------------------------------------------------
>
> Key: TRINIDAD-961
> URL:
https://issues.apache.org/jira/browse/TRINIDAD-961
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 1.2.6-core
> Environment: All
> Reporter: Kamran Kashanian
> Attachments: trinidad_1.2.x.patch
>
>
> If a UIComponent inside the table column header/footer
contains a partialTrigger referencing the component ID of a
stamped component inside the table. When the partialTrigger is
invoked, the client ID that gets added to the partialTargets
list for the header/footer UIComponent includes the table
"currency" key. So the component inside the column
header/footer is incorrectly being treated as a stamped
component. This prevents the update of components inside table
header/footer (as a result of changes in stamped components in
the table body) using partialTriggers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
