[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] JSF Page Editing

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:
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: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx]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" <gerry.kessler@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

12/19/2005 12:11 PM

Please respond to
"gerry.kessler@xxxxxxxxxx" <gerry.kessler@xxxxxxxxxx>; Please respond to
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>

To
David M Williams/Raleigh/IBM@IBMUS, "wtp-dev@xxxxxxxxxxx" <wtp-dev@xxxxxxxxxxx>
cc
Subject
[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
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev