That's not what I'm saying..
Interfaces absolutely have their place. But this is not an interface,
it's an abstract class and rightfully so. An interface is good for
providing one-way dependencies. That is, for exposing something which
always has a well known implementation that may be hidden from the
user. One of the "problems" with interfaces, however, is that using
them does not provide the flexibility to add apis and remain binary
compatible on the implementation side without the use of inheritance.
Indeed in Java when its needed to extend an interface, it's added
sub-interfaces.
This class (like UIComponent in JSF) it is intended for people to write
components against whereas the base class should be a default
implementation to make things easier. When Faces needed to extend the
functionality of its UIComponent class from 1.1 to 1.2, it did exactly
what I'm proposing. So what I'm proposing is not off base. When Adam
was more active on this list he was really zen about making sure
compatibility wasn't breached. I feel that, in general, its helped us
more then hurt us which is why I brought it up here. Correctness and
compatibility should always win over beautiful code.
That said, I totally buy the argument that nobody using Trinidad is
currently implementing the UIXComponent interface without using the
UIXComponentBase object. In this case, I believe your argument is that
it's fine to break contract because we would have a known implementation
as the only implementer of this interface because everything else
extends the UIXComponentBase. That may be true, but in order for us to
know that we need to at least ping the list about it and see if it is
going to mess with people in the community at large who would be
depending on this API. I don't by the "let's break it and see if anyone
complains" attitude, and that is the precedent I was referring to.
This is why I mentioned that I'm willing to concede the point if nobody
on the list has a problem with it.
Scott
Blake Sullivan wrote:
Scott O'Bryan said the following On 3/10/2008 3:24 PM PT:
Well you know my vote, I'm concerned about the incompatibility
If I really thought there was much of a chance that anyone had already
subclassed UIXComponent itself, I would be more worried.
and, frankly, having it only in base provides us nothing but a nicer
looking class.
I guess you aren't a fan of interfaces for anything other than
co-implementation either, then.
Ultimately though, if nobody else cares I'm willing to let it
slide. I just think it sets a bad precedent.
Precedent for what? Weighing long-term cleanliness against the
likelihood of regression? It seems that your disagreement is with the
relative weighting of the advantages and disadvantages in this case,
which is a fair complaint but isn't precedent setting.
-- Blake Sullivan
Scott
Max Starets wrote:
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)
<[email protected] <mailto:[email protected]>> 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.
