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
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of David M Williams
Sent: Tuesday, January 03, 2006 11:11 PM
To: General discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] JSF Page Editing
Gerry,
Yes, this is not a good candidate for "content type" extension, and some how we should make it "automatically" part of JSP editing.
- JSF EL support
I'm surprised this doesn't work "out of the box". I meant to run through one of your examples, but haven't had time yet.
- content assist/Quick Fix create for managed beans
My first thought is to add functionality via an INodeAdapter, with an appropriate (and fast) adapter factory). Let's write-up some specific example cases and I can give better advise.
- hyperlink to managed beans
Might be sufficient to do with with "heuristics" (without full java model) ... that is, if its looks like a class, just try to open it as a class. I'm guessing this would work at least 95% of the time, but tell me if I'm being overly simplistic.
David
"Gerry Kessler" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]12/19/2005 12:11 PM
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; Please respond to
"General discussion of project-wide or architectural issues." <[email protected]>
David M Williams/Raleigh/[EMAIL PROTECTED], "[email protected]" <[email protected]> [wtp-dev] JSF Page Editing
David et al,
The JSF Tooling Team is starting to take a closer look at how we will be providing enhancements to the JSP Structured Editor and we have a whole bunch of questions.
Some of the enhancements that we are considering:
- JSF EL support
- content assist/Quick Fix create for managed beans
- hyperlink to managed beans
Taking a(n incomplete) look at the SSE architecture, it leads me to think that the way we should implement is to (minimally) provide our own SourceViewerConfiguration via the org.eclipse.wst.sse.ui.editorConfiguration ext-pt. I am thinking our StructuredContentViewer would subclass the StructuredTextViewerConfigurationJSP as is suggested by "webtools\wst\components\sse\designs\EditorConfiguration.html".
However, what I am stuck on is that there appears not to be a new target content type. A JSF page is just a JSP page and a user would expect to be able to use .jsp file extensions. Does the file extension determine which editor configuration that will get used? If the user opens a JSP file and added JSF content (jsf taglib imports and jsf elements), can the configuration suddenly switch to use JSF?
Undoubtedly the SSE/JSP team has thought a little about support for JSF and I was looking for advice on what would be the best way to progress. Would it be better if we provided enhancements directly to the JSP editor?
Hopefully these aren't totally stupid questions. Any pointers you can provide would be great and if you would prefer to take this off-line, that is fine too.
Thanks,
Gerry Kessler
WTP JSF Tools Team
_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
