Community
Participate
Working Groups
I noticed that the as-you-type EL validation preference for JSP/JSF context has no impact and is ignored. The behavior for as-you-type EL validation defaults to Build/Run EL validation preference. I.E., when as-you-type EL validation preference is disabled and Build/Run EL validation preference enabled, the JSFValidator will validate the document as you type! The default preference setting is to disable as-you-type EL validation, but since this is broken, the user will still get as-you-type EL validation. If the page is long and validation is slow, the user's only option is to turn off the Build/Run EL validation. To reproduce: 1) create JSF 1.2 faceted DWP 2) create faces jsp page 3) disable as-you-type EL validation in the Window Preference, "Web | JavaServer Faces Tools | Validation" 4) drop commandButton into the page 5) type EL into the value attribute, something like... <h:commandButton value="#{facesContext.foo}"> Result: as you type but before saving the document, note the yellow squiggly and that hovering over the attribute will yield "foo cannot be resolved as memeber of facesContext" Expected: no feedback until the document was saved.
Here's an analysis of the problem... The "as-you-type" sourcevalidation extension point for the JSFValidator class is registered with a validator attribute of scope="total". This implies that the "total" document rather than "partial" is validated each time validate is called. In the SSE class, ReconcileStepForValidator, the reconcileModel() method checks that the validator scope is "partial" (not "total") as well as being an instance of ISourceValidator, before going down a code path that would eventually call the JSFValidator implementation of ISourceValidator.validate(Region, IValidationContext, IReporter) and in turn the version of XMLViewDefnValidator.validateView() that creates a JSFValidationContext with the _isIncremental flag set to true. Instead, the code path in ReconcileStepForValidator.reconcileModel() for as-you-type validation for scope="total" will call the IValidator.validate(IValidationContext, IReporter) on the JSFValidator instance. JSFValidator does not override this method so it defaults to the parent class implementation in JSPValidator which calls JSFValidator.validateFile() and in turn calls a different version of XMLViewDefnValidator.validateView() that creates a JSFValidationContext with the _isIncremental flag set to false. Therefor, the _isIncremental flag in JSFValidationContext will always be false and the method JSFValidationContext.shouldValidateEL(), with the following logic, if (_isIncremental) { return _prefs.getElPrefs().isEnableIncrementalValidation(); } return _prefs.getElPrefs().isEnableBuildValidation(); ...will always determine to validate EL depending on only the Build/Run preference setting.
Should also note that the code path of the validation builder job eventually calls the validate(IResource, int, ValidationState, IProgressMonitor) method of a validator that extends org.eclipse.wst.validation.AbstractValidator. For the JSFValidator and Build/Run EL validation, this defaults to the implementation in the parent class, JSPValidator, which extends from AbstractValidator. The JSPValidator implementation of this validate method calls JSFValidator.validateFile() and in turn calls the version of XMLViewDefnValidator.validateView() that creates a JSFValidationContext with the _isIncremental flag set to false.
I think we should consider fixing for RC3. If users experience performance hits for as-you-type validation on the "total" document which is large and requires lots of processing, the only way for them to turn it off is to disable the Build/Run EL validation, implying no more EL validation. Setting this to 3.2 RC3.
Created attachment 169433 [details] patch to set the scope of the JSFValidator to "partial" for as-you-type EL validation This patch changes the scope of the JSFValidator to "partial" for as-you-type EL validation. The source validation implementation in JSFValidate just constructs the JSFValidationContext with _isIncremental set to true and then via a call to XMLViewDefnValidator will end up going through the same code path that was followed when the scope was "total". The only difference was that before the call to XMLViewDefnValidator.validateRegions() when scope was "total" was that all the regions of the document were passed in to process, rather than just the dirty regions. With a JSFValidationContext with _isIncremental as true, the context will now test and return the value of the "as-you-type" EL validation preference. Just setting the scope="partial" will solve this issue. Requesting PMC approval for 3.2 RC3.
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. The Preference setting to disable as-you-type validation is being ignored and hence users will not be able to disable this validation if ,say, they encounter a performance issue with this feature. * Is there a work-around? If so, why do you believe the work-around is insufficient? No reasonable workaround. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Manual testing * Give a brief technical overview. Who has reviewed this fix? See comment 4. * What is the risk associated with this fix? none
sounds like some complicated code paths, but change looks simple enough, if this reflects the desired behavior. I'm fine either way, but is it the case that the partial scope really is what is desired ... or is changing it to that sort of a work around? (Just not clear from my quick read ... but I am fine with the change. Sounds like better uer experience and control.)
(In reply to comment #6) > sounds like some complicated code paths, but change looks simple enough, if > this reflects the desired behavior. Yes, and in the end my descriptions may have made the code paths sound more complicated than they are. Eventually the handling for the partial scope and total document validation end up going through the same validation code. The total document validation gets all the partitions and passes them along the same code path. The main difference is that with the partial scope it is just the dirty regions that are processed. Along the way, the implementation of the source validation interface allows a context to be configured so that the shared code path will correctly check for the setting of the as-you-type preference. > > I'm fine either way, but is it the case that the partial scope really is what > is desired ... or is changing it to that sort of a work around? (Just not clear > from my quick read ... but I am fine with the change. Sounds like better uer > experience and control.) Thanks David. Yes, as I understand it, I think partial scope will be OK here for JSF EL validation. There may be a few scenarios that I have not considered where a total document validation would be required but the work around there would be a page save for a build/run event to get the full page validation. Unfortunately, without this change the user has no control of the as-you-type EL validation. It is either always on with the build/run validation or completely off by turning off EL validation.
Patch committed to HEAD for 3.2 RC3.
