JSF composite component's attribute code completion

[lfryc]

Hi guys,

I was thinking about support for code completion of composite  component's attributes (cc:attribute) inside composite component's  interface (cc:interface) in JBoss Developer Studio (or other IDEs).

Currently (JBDS 4.0.0.Beta2) there is no support for code completion of  #{cc.attrs.*} expressions other than completion of the component's  attribute name. But there is the way we can derive the actual type of  component's attribute.

JavaServer Faces 2.0: The Complete Reference [1] states that  cc:attribute 'type' attribute is "The fully qualified name of a class that  defines the type of value that the using page author must specify in  the value attribute of the composite component tag. The default value is  java.lang.Object".

For example if I want to design composite component with attribute of type List<String>, I simply can limit the type of attribute to  type="java.util.List". Which is not pretty usable for code completion as  long as IDE can't evaluate the actual type given in composite  component's interface.

This support cannot work completely without proper support in JSF for generic types.

The question is: isn't this something we want to push to JSF specification to improve support in IDEs?

Since JSF is specification from the outset designed to have good support across IDEs, the answer can be pretty clear.


[1] Ed Burns, Chris Chalk; JavaServer Faces 2.0: The Complete Reference; McGraw Hill

[jbalunas]

Lukas,

I like this idea, and think we should discuss the details of getting this into the spec, or at least proposing it.  We may even be able to prototype this through RichFaces/CDK and tools.

I recommend continuing this conversation here, with tools, but also search for a related spec issue.  If you don't find one - create one.  Then we can discuss how to get your idea in spec form.

-Jay

[akazakov]

Lukas,

what kind of code completion tools could support in case <composite:attribute type="..." ...> defined?

For example we have:

<composite:attribute name="label"/>

<composite:attribute name="value" required="true"/>

<composite:interface>

      <composite:attribute name="value" type="java.util.List"/>

</composite:interface>

It means that if we have <ez:comp value="#{x.y.z}"/>, then #{x.y.z} must be evaluated to java.util.List, correct? We could validate such ELs but how we could provide a better code completion?

It seems that I didn't get your idea. Sorry, I don't know JSF 2 spec. well enough

[alexsmirnov]

I think this is Java JRE limitation - runtime code eliminates generic information, so there is no difference between List and List<String> passed to any method. JSF EL uses reflection at runtime, so it also has no clue about generic values.

The second problem that EL has been designed at JRE 1.4 age, so speck ignores generics at all, even if such information available at runtime.

[lfryc]

<cc:interface>
     <cc:attribute name="list" type="java.util.List" />
</cc:interface>

<cc:implementation>

<h:dataTable value="#{cc.attrs.myattr}" var="item">
     <h:column>
          #{item.property}
     </h:column>
</h:dataTable>

JBDS can provide code completion for #{cc.attrs.list}.

But it doesn't provide the #{cc.attrs.list.empty} or #{cc.attrs.list.size()}.

With support of generics, we can also use code completion for #{item.property} or #{cc.attrs.list[0].property}.

[lfryc]

You are right Alex, provide information like type="java.util.List<mypackage.MyObject>" may be useful for IDEs to run validation, completion, etc. .

[akazakov]

Ok. Now I got your idea. And yes, if JSF spec had possibility to define generic types JBT could support such code completion. BTW so far we can at least implement such a feature for full qualified not-generic type names at least. I will create a feature request.

[akazakov]

https://jira.jboss.org/browse/JBIDE-7439

[jbalunas]

I think Alex's point on runtime generic information is key here though. 

There is no way to get that info from JRE, so this would be extra meta-data that JSF would need to provide.  Although we would then need to think about compile/runtime with the composite components as well.

[lfryc]

The fact is that it's a pain to develop the complex composite components structures since you have no tool to infer actual type of expressions inside component.

The current IDEs are very strong in inferring types from current model and following validation of view definition.

But the composite component are introducing the problem for them.

Yes, we cannot handle the generic types at runtime, but this is the same situation like in Java language itself, consider:

It's the matter of compiler to guard the right type of generics in Java language <-> it's the matter of validator to guard the right type of generics in composite components.

IDEs can use the type information to help programmes in both cases.

And in the JSF implementation, it means only dealing with specific part of the @type / @method-signature attributes.

<composite:interface>
      <composite:attribute name="value" type="java.util.List<my.package.Person>"/>
</composite:interface>

[maxandersen]

Couldn't agree more; at first I was thinking that the <> characters would be a problem but seems like that is all valid in XML strings so this works well for me.

[akazakov]

Now JBT supports code completion for generics in Java code. For example if we have a managed bean with the following method:

java.util.List<my.package.Person> getList() {...}

Then code assist will work for such an EL:

<h:dataTable value="#{bean.list}" var="item">

    <h:column>

         #{item.property}

    </h:column>

</h:dataTable>

So if JSF2.* supports generics in composite components like <composite:attribute name="value" type="java.util.List<my.package.Person>"/>

then it's not a very big problem to support it in code assist.

[jbalunas]

That is good to hear, and I think that we should push this in the EG for 2.2 ? 

Lukas: Not sure if you already did, but can you create a JSF spec jira for this.  Once that is done can you update http://community.jboss.org/wiki/RichFacesJSF21ProposedEnhancementsandIssues with this issue. 

Alex, Nick, Dan, & Lincoln : assuming you are going to be on the JSR EG - it would be good if you could review and push this!

-Jay

[lfryc]

Hi Jay, JIRA created at http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-916