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
