Community
Participate
Working Groups
Build Identifier: I20100527-1700 Even though the JSF 1.2 tag lib documentation shows that the "url" attribute of the JSF HTML "graphicImage" tag and the "image" attribute of the "commandButton" tag are ValueExpressions, the metadata does not reflect this. It doesn't look like the metadata automatically shows this for every attribute that can be a ValueExpression, but it would be useful to have it for these attributes. Thanks. Reproducible: Always Steps to Reproduce: 1. This happens in our product (Oracle Enterprise Pack for Eclipse) when we access the metadata for these two attribute. 2. I don't know a good repro case for straight JSF, but inspecting the metadata directly should show what I'm talking about.
Duplicate of bug 319189 ?
(In reply to comment #1) > Duplicate of bug 319189 ? No, I don't believe this has anything to do with DTInfo metadata - I could be wrong. Preston?
I thought it had to do with the metadata in org.eclipse.jst.jsf.standard.tagsupport/metadata. Specifically, I was looking for something like: <entity id="graphicImage" type="tag"> ... <entity id="url"> <trait id="attribute-value-runtime-type"> <value xsi:type="mdt:StringValue">org.eclipse.jst.jsf.core.attributevalues.ValueBindingType</value> ... </trait> ... </entity> And the same for the "image" attribute of the "commandButton" tag. Instead, it has type org.eclipse.jst.jsf.core.attributevalues.WebPathType. This is all in the jsf_html.xml file. I'm no expert in this, but I think this is where the issue lies.
(In reply to comment #3) > I thought it had to do with the metadata in > org.eclipse.jst.jsf.standard.tagsupport/metadata. Specifically, I was looking > for something like: > <entity id="graphicImage" type="tag"> > ... > <entity id="url"> > <trait id="attribute-value-runtime-type"> > <value > xsi:type="mdt:StringValue">org.eclipse.jst.jsf.core.attributevalues.ValueBindingType</value> > ... > </trait> > ... > </entity> > And the same for the "image" attribute of the "commandButton" tag. Instead, it > has type org.eclipse.jst.jsf.core.attributevalues.WebPathType. > This is all in the jsf_html.xml file. > I'm no expert in this, but I think this is where the issue lies. Right. It looks like it's metadata-related, but this is different metadata than is used for "tag converting" for rendering, so this bug is not a duplicate of Bug 319189.
Preston, what exactly is affected by this "missing metadata"? This is not metadata that I am familiar with, so please advise what behaviour or functionality is missing or broken and what is expected instead. Thanks, - Ian
Deferred due to lack of resources.
Let's look at this one from the symptoms; I'll stop trying to say what I suspect the metadata should look like. So, back to the JSF 1.2 document: the "url" attribute of the JSF HTML "graphicImage" tag and the "image" attribute of the "commandButton" tag are ValueExpressions. Given that, I have a call to return MetaDataEnabledProcessingFactory .getInstance() .getAttributeValueRuntimeTypeFeatureProcessors( adapterType, // IValidELValues.class sdContext, // DefaultStructuredDocumentContext uri, // http://java.sun.com/jsf/html elementName, // graphicImage attrName); // url Why does it return Collections$EmptyList for the IValidELValues adapter type when the JSF 1.2 docs say the attribute is a ValueExpression?
Preston, Thanks for the info. I have also spoken to others about this. What I am asking is what functionality is broken by this, what feature fails to work, etc? How do I test this (other than by writing code and observing the return value)? Based on what I have learned, I suspect that the observable functionality is possibly minimal within the JSF Tools project itself but much more obvious in adopter products that make use of API/features offered by the JSF Tools project. Again, thanks, - Ian
Ian, you're right in saying that the observable functionality is in the adopter products that make use of API/features offered by the JSF Tools project. Our product puts up an EL dialog when it detects the value expression case (and others too). Without this fix, we don't know to put up the EL dialog. I don't have a case where you can test this in the open source code.
Mass Triage: Deferred from Indigo
Changing the Target Milestone to future
