Bug 199853

Summary: ContentAssist: Improve parent symbol resolution
Product: [WebTools] Java Server Faces Reporter: Matthias Fuessel <mat.fuessel>
Component: CoreAssignee: Ian Trimble <ian.trimble>
Status: NEW --- QA Contact:
Severity: enhancement    
Priority: P3 CC: cameron.bateman, carlin.rogers, raghunathan.srinivasan, xiaonan_jiang
Version: 2.0Keywords: helpwanted
Target Milestone: Future   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
patch to unify el parsing for ContentAssist and validation
none
updated version, handles someList[-1] correctly none

Description Matthias Fuessel CLA 2007-08-14 07:23:03 EDT
ContentAssist doesn't take into account type parameters for lists/maps while semantic validation does, i.e. if "beanList" is a List<SomeBeanType> and you invoke CA on "beanList[12].", you only get the properties/methods of "Object", not of "SomeBeanType".

Currently, there are two completely independent algorithms for resolving symbols in el expressions: a very simple one in ContentAssistParser, that is used for content assist (and that doesn't know about typed lists/maps) and a more capable and much more sophisticated one in ASTSemanticValidator, that is used for validation.

At least the results of both should be equivalent.
Comment 1 Matthias Fuessel CLA 2007-08-14 07:49:18 EDT
Created attachment 76035 [details]
patch to unify el parsing for ContentAssist and validation

This patch tries to base symbol resolution (for ContentAssist and other purposes) and validation on the same el parsing logic. Therefore, it extracts a new superclass "ASTTraverser" out of ASTSemanticValidator, on which both ASTSemanticValidator and the new ASTResolver - for resolving symbols in el expressions - are based. ContentAssistParser now uses ASTResolver.
The patch also makes parsing of "[]" operator recover from unknown/erroneous second parameter if first parameter is a Map. And finally, it make MemberOperator ("[]" and ".") do validation and result calculation at the same time, since it mainly does the same thing for both purposes.

(Getting the "usual" value type of a map by simply passing it an arbitrary string as key is a bit of a hack. Probably this can be done better...)

user-visible improvements are:
-ContentAssist benefits from typed lists/maps
-result of el parsing is consistent throughout jsf tooling

Improvement for development is that the complex logic of parsing el expressions has to be implemented/maintained in only *one* place.

The downside is that ASTTraverser still contains some validation-specific stuff, since in some places this would be separable only for the price of much more complexity.
Comment 2 Cameron Bateman CLA 2007-08-21 16:23:22 EDT
Hi Matthias,

This looks like a really useful enhancement!  Has the patched code passed the regression test suite (particularly org.eclipse.jst.jsf.validation.el)?


--Cam
Comment 3 Matthias Fuessel CLA 2007-08-27 17:22:52 EDT
Sorry, I didn't manage to do this before my vacation. So this has not been regression-tested. There are also two known issues: CA on subproperties of *unknown* objects/properties gives all instance symbols instead of no proposals, and CA on *empty* or unmatched "[" bracket fails because JSP EL parser fails with ParserException. I will be able to spend some time on this about 5/6 weeks from now, but not earlier.
Comment 4 Matthias Fuessel CLA 2007-11-20 09:13:11 EST
Created attachment 83328 [details]
updated version, handles someList[-1] correctly

Some smaller changes, most notably List/array access with index < 0 is handled correctly (error, continue with index 0).

This version passes validation.el tests.

Unfortunately it brakes contentassist tests completely, because it is no longer possible to calculate some prefix for an el expression without a file containing this expression. This breaks only the tests, no real usecase.

The (minor) problems mentioned in comment 3 still exist, the second one (CA on mismatched/empty "[" operator fails) occurring also with current, unmodified jsf tooling.

A binary version containing all my changes can be downloaded for testing from
http://www2.informatik.hu-berlin.de/~fuessel/eclipse/eclipse.html#jsf_ext
Comment 5 Raghunathan Srinivasan CLA 2008-04-15 17:40:47 EDT
Deferred due to lack of resources.
Comment 6 Raghunathan Srinivasan CLA 2010-10-06 19:25:37 EDT
For review.
Comment 7 Raghunathan Srinivasan CLA 2010-12-28 16:01:32 EST
For review
Comment 8 Raghunathan Srinivasan CLA 2011-03-11 17:55:28 EST
For review
Comment 9 Raghunathan Srinivasan CLA 2011-03-15 13:52:22 EDT
Deferred to next release due to lack of resources. The underlying code on which this patch is based has changed and hence requires more work to absorb this fix. We will revisit in the next release. 
We appreciate the code contribution and look forward to any help from the community on this bug.