Hi
I have checked if there is some related code and doing this:
/**
* Disable this property; although this class extends a base-class that
* defines a read/write rendered property, this particular subclass
* does not support setting it. Yes, this is broken OO design: direct
* all complaints to the JSF spec group.
*
* JSFProperty tagExcluded="true"
*/
public void setRendered(boolean state) {
throw new UnsupportedOperationException();
}
works without problem (override isRendered is bad, because this method is
used on processXXX and encodeXXX methods).
I'll commit those changes tomorrow (Today is holiday in Colombia).
regards
Leonardo Uribe
On Sun, Jun 1, 2008 at 4:29 AM, simon <[EMAIL PROTECTED]> wrote:
>
> On Sat, 2008-05-31 at 16:45 -0500, Leonardo Uribe wrote:
> > Hi
> >
> > On Sat, May 31, 2008 at 2:48 PM, simon <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Here are some things I noticed when reviewing the tlddocs for
> > core11-based-on-myfaces-builder.
> >
> > Tag f:selectItems now has a "rendered" attribute, which it
> > should not.
> >
> > This problem is caused because the plugin enforces inheritance of
> > properties. The solution is do something like this:
> >
> > * @JSFComponent
> > * name = "f:selectItems"
> > * bodyContent = "empty"
> > * tagClass = "org.apache.myfaces.taglib.core.SelectItemsTag"
> > * desc = "UISelectItems"
> > * @JSFJspProperty name = "rendered" returnType = "boolean"
> > tagExcluded = "true"
> > */
> > public class UISelectItems extends UIComponentBase
> >
> > When the hierarchy is merged, tagExcluded = "true" takes precedence,
> > so this property is not mentioned on tld anymore.
>
> I actually think the problem is that the OO inheritance hierarchy in the
> JSF spec is wrong. If UISelectItems does not support the "rendered"
> property, then it should not subclass something that does. This breaks
> the principle of substitutability, which is one of the fundamental
> concepts of OO programming:
> http://en.wikipedia.org/wiki/Substitutability
>
> This does appear to be a problem in the spec, not in our code. However I
> don't agree with the solution of just excluding the property from the
> tag; that fixes only part of the issue by blocking JSP tags from
> accessing the property, but nothing else.
>
> I would instead suggest something like this in the
> UISelectItem/UISelectItems classes:
>
> /**
> * Disable this property; although this class extends a base-class that
> * defines a read/write rendered property, this particular subclass
> * does not support setting it. Yes, this is broken OO design: direct
> * all complaints to the JSF spec group.
> *
> * JSFProperty tagExcluded="true"
> */
> public void setRendered(boolean state) {
> throw new UnsupportedOperationException();
> }
>
> Actually, I would suggest renaming tagExcluded to "ignore". This is not
> a jsp-tag-specific issue; any view templating language including
> facelets, clay, and whatever else gets invented, should act as if this
> method is *not* a JSFProperty even though the inherited settings say it
> is.
>
>
> What do you think?
>
> Regards,
> Simon
> >
>
>
