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]> 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) < > [email protected]> wrote: > > > > > [ > > 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. > > > > >
