Hi David,
Sorry that this response has taken so long.
Raghu has been working on the use cases/requirements and I was going to
wait till that was published. However, I think I can adequately
describe some of our desired features and the issues that we have.
This is not a complete list and is meant to get some discussions moving.
1) JSF EL - is not currently supported in the
current JSP editor but is required for many of the other enhancements
we are considering. There are many similarities with JSP EL but they
are not quite the same. More importantly is that in the current JSP
editor, the system does not even recognize it as an EL region. A JSF
EL _expression_ begins with #{ rather than ${. So at first blush, if
we want to support JSF EL regions, we would need at least a new
partition type and a new EL parser/tokenizer.
In a separate e-mail Raghu had asked about
support for JSP 2.1 EL in the JSP editor for WTP 1.5. That EL unifies
the JSP and EL parser in J2EE 5 and were considering the possibility of
not supplying a JSF 1.0/1.1 EL. However, we feel it highly desirable
to support the current JSF EL anyway and, if we were to tackle it, we would
probably need some guidance.
2) Content Assist - as we were breaking down
the requirements for this, we realized that this takes many forms and
there are varying degrees of support in the current editor. Assist for
JSF tags works out of the box as expected. Content assist for
attribute values is where it
gets tricky. We have broken that down further to EL and non-EL
attribute values. Some examples:
- For a tag with a "value" attribute, using EL,
it would be nice to present the user with a list of the possible
managed beans and the methods/properties of a resolved bean. In JSF,
btw, all objects get resolved by looking up it's name in the one or
more configuration files. In the case of a managed bean, the name is
mapped to a class element in a config file.
- For a tag with an
"action" attribute, it would be nice to present a list of the available
navigation outcomes for the page defined in the config file. A user
could also start to type in EL, and should then be presented with
available managed beans and their properties/methods.
I think I see how we could go
about providing the content assist for a JSF EL region, but how would
we go about doing it for non-EL attribute values? First off, I think
we would first need to know if it were inside a JSF JSP tag(?). Then,
I suspect that we would need to provide very specific proposals for
known attributes of known tags.
For tags not
defined in the JSF spec, we think it would be nice to have an
extension point of some kind that would allow someone to provide
proposals for other tags and attributes. This, of course, is not
really specific to JSF and could be valuable to anyone using tag libs.
3) Quick Fix - one example: if a managed bean
referenced in EL cannot be resolved, we would like to have a quick fix
proposal to create the class (and/or method/attrbute) just like one
expects in the JDT Java editor. This would create the Java class and
also create the reference in the configuration file. We would like to
be able to do similar things for non-EL references like action
attributes and others.
4) Hyperlink - you may be right that
"hueristics" may be sufficient for managed beans. If an identifier
can be resolved as a managed bean, we could open the class defined in
the config file.
All of the above are highly interrelated and many hinge
around the JSF EL parser. However even more importantly is that if
there is no new "content type", the implementation would need to live
in the JSP plugins unless we want the
user to choose "Open with.." to choose a separate JSF JSP Editor.
It may be very useful to have a phone conversation between our 2 groups
to discuss your plans and ours. We don't want to step on anyones toes
and we will require your
advice on many points.
Regards,
Gerry Kessler
WTP JSF Tools Team