Declaring component attributes via annotations

[eclipse-faces-bot]

As of #594, custom components can be declared to be useable in Facelets via the @FacesComponent annotation. Via this it's no longer required to have an entry in a taglib.xml file.

However, if the component author wishes to declare the component's attributes (for documentation, tooling, etc), XML still has to be used.

I therefor would like to propose declaring these attributes via annotations as well.

E.g.

@FacesComponent(value="components.CustomComponent", createTag=true)
public class Foo extends UIComponentBase {

    @Attribute
    String color; // will be injected with getAttributes("color") 
    @Attribute(description="This will determine the ...", required=true)
    String style;

    @Attribute(description="The cost of ... ", default="100")
    Integer cost;

}

[eclipse-faces-bot]

@glassfishrobot Commented
Reported by @arjantijms

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

[eclipse-faces-bot]

@glassfishrobot Commented
@manfredriem said:
Setting priority to Critical

[eclipse-faces-bot]

@glassfishrobot Commented
c.beikov said:
In my opinion the @Attribute annotation should go on an abstract getter and the component class should be declared as abstract. This way you could define reusable behavior in interfaces and inherit these attributes by implementing an interface.
The runtime can just generate an appropriate subclass of a component class that implements those methods. This also gives the implementation flexibility regarding the representation of the data.
If the values of EL expressions are bound to the component instance on creation of the component, how would the component get a changed value if the original EL expression would evaluate to a different value later in the lifecycle?

I implemented an annotation processor that generates these Java classes and XML files based on annotations for me at build time. I think Richfaces did something similar. JSF could just move that process to the runtime.

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
"Properties" is a hot button topic. It was recently booted out of Java SE 9. This is a decent writeup: http://blog.joda.org/2014/11/no-properties-in-java-language.html

[eclipse-faces-bot]

@glassfishrobot Commented
This issue was imported from java.net JIRA JAVASERVERFACES_SPEC_PUBLIC-1193

[eclipse-faces-bot]

@tandraschko Commented
We should really work on something for the next version. The current behavior is a pain for component developers.
In PrimeFaces we generated this via a mojo and currently we think about switching to a better approach like mentioned here.
Here is the topic about it: primefaces/maven-jsf-plugin#4

[eclipse-faces-bot]

@arjantijms Commented
This was very high on my wish list for 2.3, so +1

[eclipse-faces-bot]

@NicolaIsotta Commented
+1

[eclipse-faces-bot]

@Rapster Commented
I recently discover this topic, so I'm quite pleased to see people came up with this idea. I started to develop an annotation processor for primefaces, but not finalized at all... @arjantijms as Thomas said, you can read the post, there is few ideas of how I'd like to do (more precisely; https://github.com/Rapster/primefaces/tree/fix-primefaces-with-cdk)

The idea is to use annotations on the component implentation, and generate a parent class contaning all getters and setters. Yes it's strange, but I don't have a choice since there are calls to setters and getters in the impl. (I could generate an interface containing all these getters and setters though) Suggestions are more than welcome 😉

If possible I'd like to use @FacesComponent but as i said so far, it's primefaces based. And Thomas mentionned issues with this annotation depending which container is used

[eclipse-faces-bot]

@arjantijms Commented
This is indeed still in scope for a next version of JSF. When the new EG is formed (or just group of committers as per Eclipse nomenclature) we should absolutely discuss this.

One more old example of the proposed syntax here: http://arjan-tijms.omnifaces.org/2012/05/simple-java-based-jsf-22-custom.html

We did discuss this somewhat previously and I think the idea that got most support then was to go for a component model based on interfaces, where the base class of a component (UIComponent) doesn't contain most of the framework itself. For compatibility, the component tree should perhaps still be UIComponent based, with UIComponents delegating to the newer style interface and annotation based components.

[eclipse-faces-bot]

@Rapster Commented
Sounds nice, since I've been working on primefaces-cdk I came up with a few ideas, the goal being code is documented by itself

• Add description to @FacesComponent
• Add annotation (e.g @FacesFunction) to register JSF static function

Do you have any idea when the new EG is formed? I know from there, you will figure out what happens next in JSF ecosystem which I'm looking forward to hear about

[eclipse-faces-bot]

@arjantijms Commented

Add description to @FacesComponent

Something along these lines indeed ;)

Do you have any idea when the new EG is formed?

Not really, other than that it should be 'soon' that the Mojarra transfer is done, which would be a major milestone toward that.

[eclipse-faces-bot]

@Rapster Commented
i'm thrilled to hear that ;-) One more thing, @Attribute will be a CDI annotation?

[eclipse-faces-bot]

@arjantijms Commented
It should almost certainly be CDI based, but it's up to the input of the group too to give their opinions about this.

[eclipse-faces-bot]

@tandraschko Commented
Yep. CDI probably also means that a component will be proxied. Not sure about the performance then and if it's even required.
We have to be carefull about changes in the component tree.
Maybe we don't even need any getter/setters, just a clean public API to access properties by name/enum (like PropertyKeys currently in PF). @Attribute could be just used by the IDE for code completion and this stuff.

But we can discuss this when the EG has been formed.

[eclipse-faces-bot]

• Issue Imported From: Declaring component attributes via annotations javaee/javaserverfaces-spec#1193
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @arjantijms