On Tue, Jul 8, 2008 at 3:46 PM, simon <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2008-07-08 at 10:35 +0200, [EMAIL PROTECTED] wrote:
> > Leonardo Uribe schrieb:
> > >
> > >
> > > On Mon, Jul 7, 2008 at 11:43 PM, Jihoon Kim <[EMAIL PROTECTED]
> > > <mailto:[EMAIL PROTECTED]>> wrote:
> > >
> > > Hi,
> > >
> > > I had some questions while refactoring the code using the
> annotations
> > > of myfaces-builder-plugin and was wondering if I was simply using
> it
> > > incorrectly or if it is yet to be implemented [since I am currently
> > > pointing to the snapshot repository of the plugin].
> > >
> > > (1) JSFProperty annotation seems to work intuitively as suggested
> in
> > > creating the get + set methods of the properties, but I was
> wondering
> > > about the properties for JSFJspProperties + JSFJspProperty.
> > >
> > > Since I wanted the components that didn't utilize the fields
> > > frequently to be pushed to the Map [so to make the code cleaner], I
> > > was hoping to use these annotations for the fields, but I
> apparently
> > > do not see them being generated within the Tag of the components
> and
> > > the tld as I thought they would be generated at.
> > >
> > > The following annotation is within a blank interface of an abstract
> > > class to be created as concrete with JSFComponent annotation :
> > >
> > >
> > > @JSFJspProperty
> > > name = "allowMultipleSelection"
> > > returnType = "java.lang.String"
> > > longDesc = "A flag that indicates whether you can allow more
> > > than
> > > one item to be selected at the same time."
> > >
> > >
> > > @JSFJspProperties and @JSFJspProperty is used only as a last resource,
> > > when you want to define a property used on the tld but not defined on
> > > the component (like "binding" property) or a parent component property
> > > should not be on the tld of the child component, and you cannot change
> > > the api of the component like in myfaces core (you cannot add public
> > > methods to components). If you are working with new components use
> > > @JSFProperty instead and avoid any usage at possible of
> @JSFJspProperty.
> >
> > But JSFProperty does assume that there is a real field on the component,
> > which is not what Jihoon Kim wants.
> >
> > I was looking at this a couple of weeks ago, and from memory one of the
> > JSFJsp* annotations really does work fine when you want real properties
> > declared in the tld (and present as methods on the tag class) but just
> > want the data pushed into the component's attributes map rather than
> > stored as a property on the component. So I was going to propose
> > renaming that annotation to JSFAttribute. Unfortunately I cannot
> > remember which annotation it was. I'll have a look on my home pc after
> > work today.
> >
> > I guess the alternative is to put a flag on the @JSFProperty annotation
> > to indicate that it is an "attributes map only" property. But that does
> > require a real method on the component to attach the annotation to,
> > which is not right for attribute-map-based properties. Maybe we could
> > allow an @JSFProperty annotation to be attached to a public static final
> > string field on the component itself; each component that supports an
> > attribute really should have a constant defined which other classes can
> > then use to fetch that attribute from the attributes map. When the
> > plugin finds a JSPProperty annotation attached to a constant, then it
> > could set the internal "isAttribute" flag on the corresponding
> > PropertyMeta object so that we know to skip that PropertyMeta when
> > generating the saveState/restoreState methods. Thoughts?
> >
>
> Hmm. The annotation I was thinking of was JSFJspProperty. I already
> committed the comment that it can be used for declaring component
> attributes that live only in the attributes map.
>
> But I must have misunderstood Leonardo's intention. Looking at the
> QdoxModelBuilder, there is a comment that this annotation exists only
> "to solve a problem with binding on JSF1.1" (line 1072). I don't
> currently understand what that problem might be. Leonardo?
>
This part ilustrate the parts where @JSFJsfProperty is useful. Look this
code on myfaces core 1.2:
@JSFComponent(type = "javax.faces.ComponentBase",
family = "javax.faces.ComponentBase",
desc = "base component when all components must inherit",
tagClass = "javax.faces.webapp.UIComponentELTag")
@JSFJspProperty(name = "binding" ,
returnType = "java.lang.String",
longDesc = "Identifies a backing bean property (of type
UIComponent or appropriate subclass) to bind to this component instance.
This value must be an EL expression.",
desc="backing bean property to bind to this component
instance")
public abstract class UIComponentBase
extends UIComponent
{
getBinding() or setBinding does not exists on UIComponentBase (does not have
sense), but it is defined on its tld, so we need to use it. But look what
happen on UIViewRoot.
@JSFComponent
@JSFJspProperty(name = "binding",returnType = "java.lang.String",tagExcluded
= true)
public class UIViewRoot extends UIComponentBase
{
UIViewRoot does not have binding property, so we need a way to exclude it.
In tomahawk there are other cases of the last example like this:
* @JSFComponent
* name = "t:jsValueChangeListener"
* class = "org.apache.myfaces.custom.jslistener.JsValueChangeListener"
* tagClass =
"org.apache.myfaces.custom.jslistener.JsValueChangeListenerTag"
*
* @JSFJspProperty name = "rendered" returnType = "boolean" tagExcluded =
"true"
* @JSFJspProperty name = "binding" returnType = "java.lang.String"
tagExcluded = "true"
* @JSFJspProperty name = "id" returnType = "java.lang.String" tagExcluded =
"true"
*/
public abstract class AbstractJsValueChangeListener extends UIComponentBase
{
>
> It would be interesting to also look at Tomahawk though. Don't we
> already have quite a lot of components that have properties on the tag
> that map just into the attributes map, and not to the component? I can't
> remember for the moment how that is set up, but will try to look
> tomorrow.
>
Strange case. It is valid to have a property without getter and setter on
its component class and defined on its tag class and its tld? isn't this
cause a lot of problems with facelets, because you have to write your own
handler class to manage this?. "binding" property is the only valid case
that I have found.
>
>
> Regards,
> Simon
>
>
