Bug 236008 - JSPedCSSSourceParser problem
Summary: JSPedCSSSourceParser problem
Status: VERIFIED FIXED
Alias: None
Product: WTP Source Editing
Classification: WebTools
Component: jst.jsp (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P2 major with 3 votes (vote)
Target Milestone: 3.0.1   Edit
Assignee: Nick Sandonato CLA
QA Contact: Nitin Dahyabhai CLA
URL:
Whiteboard:
Keywords: contributed
Depends on:
Blocks:
 
Reported: 2008-06-06 05:53 EDT by Chander Prakash CLA
Modified: 2008-08-19 15:22 EDT (History)
6 users (show)

See Also:
thatnitind: review+


Attachments
patch (7.80 KB, patch)
2008-07-22 11:08 EDT, Nick Sandonato CLA
bjorn.freeman-benson: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chander Prakash CLA 2008-06-06 05:53:12 EDT
Build ID: 3.4.0

Steps To Reproduce:

Code:

public final ITextRegion getNextToken() throws IOException {
		
//			text = new StringBuffer(yytext());
			start = yychar;
			textLength = length = yylength();
		}

		if (context != null) {
			if (context == CSS_JSP_SCRIPTLET || context == CSS_JSP_EL){
				nextTokenType = primGetNextToken();
				while (nextTokenType != CSS_JSP_END && nextTokenType != CSS_EL_END && nextTokenType != CSS_JSP_COMMENT) {
//					text.append(yytext());
					textLength += yylength();
					length = textLength;
					



Assume there are 3 lines in the editor that uses JSPedCSSSourceParser [styles.jsp]

(Line1) <%@ page session="false" contentType="text/css;charset=ISO-8859-1" %>
(Line2) <% pageContext.getRequest().setCharacterEncoding("UTF-8"); %>
(Line3) <%@ include file="./styles_fragment.jspf" %>

If you edit line2, then the below hierarchy is called


Hierarchy

CSSStructuredDocumentReParser(StructuredDocumentReParser).reparse(IStructuredDocumentRegion, IStructuredDocumentRegion)->CSSStructuredDocumentReParser(StructuredDocumentReParser).core_reparse(int, int, CoreNodeList, boolean) >CSSStructuredDocumentReParser(StructuredDocumentReParser)._core_reparse_text(int, int) ->JSPedCSSSourceParser(CSSSourceParser).getDocumentRegions()->JSPedCSSSourceParser(CSSSourceParser).parseNodes()->JSPedCSSSourceParser(CSSSourceParser).getNextRegion() ->JSPedCSSTokenizer.getNextToken() 	



Why node/region calculation fails

CSSStructuredDocumentReParser(StructuredDocumentReParser).core_reparse(int, int, CoreNodeList, boolean) in newNodesHead it is having <% pageContext.getRequest().setCharacterEncoding("UTF-8"); %>
<%@ include file="./styles_fragment.jspf" %> both the lines as a single node and its nextnode is null. From above hierarchy you can see that finally it calls JSPedCSSTokenizer.getNextToken() method 
In this case value of  nextToeknType it does not change its value to CSS_JSP_END when it encounter with “%>” character, Instead of this it start counting the character it goes to 3 lines, when it get “%>” character in 3rd line and it value of nextToeknType become CSS_JSP_END and it consider both the lines as a single node. So in this case value of newNodesHead is <% pageContext.getRequest().setCharacterEncoding("UTF8"); %>
<%@ include file="./styles_fragment.jspf" %>
 As a single node instead of considering it two different node.

 

Why node/region calculation passes if line2 is modified to have @ or =

 But if we modify 2nd line and make it either <%@ pageContext.getRequest().setCharacterEncoding("UTF-8"); %> or <% int i=0 %> then newNodesHead is consider it as a single node and its next node is <%@ include file="./styles_fragment.jspf" %>. This problem came from fStructuredDocument.getParser().getDocumentRegions From above hierarchy you can see that finally it calls JSPedCSSTokenizer.getNextToken() method and value of nextTokenType start with CSS_JSP_Directive and it start counting the characters and when it reaches to “%>” [end of line] character, value of nextTokenType become CSS_JSP_End  and it consider it as a different node. This is because of presence of either ‘=’ or ‘@’ . Again it start with CSS_JSP_DIRECTIVE for 3rd line and end with CSS_JSP_END when it reaches “%>”character and also it store it as a different node so in this case it is having 2 nodes in newNodesHead.




What is our expectation.

When we include 2nd line it is not able to recognize the Styles those are applied on styles_fragment.jspf (3rd line) file on current file styles.jsp.
Our expectation is when we include second line it should able to recognize the styles those are applies in 3rd lines. Or It should consider second line and third line as a two separate nodes so that it can apply styles of third line on current file (in which we have included these lines). This will happen if just ‘%>’ is considered to be causing the end of CSS_JSP_END.
Comment 1 Chris Aniszczyk CLA 2008-06-06 10:17:11 EDT
moving to webtools
Comment 2 Gaurav Mising name CLA 2008-06-12 01:30:00 EDT
This bug affects the RAD functionality. When can it be fixed?
Comment 3 David Williams CLA 2008-06-12 02:09:56 EDT
This appears very complicated, I can't even understand your description on one reading ... I'll have re-read after a good nights sleep. 

but will mark it so remind us to investigate it. 


Comment 4 Madhuri Koushik CLA 2008-06-16 05:33:18 EDT
There is another CR raised by the portal team (RATLC01365570) which is pointing to the same problem. Please look into this problem since there a number of issues in RAD relating to the same problem. 
Comment 5 Saurabh CLA 2008-06-25 16:07:11 EDT
This bug affects the RAD functionality and should be fixed sooner than later. Any idea by when can this be fixed ?
Comment 6 Saurabh CLA 2008-06-25 16:09:00 EDT
This bug affects the RAD functionality and should be fixed sooner than later. Any idea by when can this be fixed ?
Comment 7 Nitin Dahyabhai CLA 2008-07-07 21:05:41 EDT
Sooner if you have a patch to propose.  Otherwise I have doubts about us spending time on it for 3.0.1.
Comment 8 Nick Sandonato CLA 2008-07-22 11:08:49 EDT
Created attachment 108074 [details]
patch

The JSPedCSSTokenizer was always chewing up tokens in the context CSS_JSP_SCRIPTLET considering them to be part of a CSS_JSP_COMMENT.  Added a test case that emulates the sample from the description.
Comment 9 Nitin Dahyabhai CLA 2008-07-22 18:08:24 EDT
Fixed, thanks, Nick.
Comment 10 Chander Prakash CLA 2008-08-05 04:57:05 EDT
We have one more problem which has not been solved by your fix.This is also a parser problem where it is failing to parse background color.

Steps to reproduce the problem.

bugzilla link:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=236008

In above problem insert following code in styles_fragment.jspf file or any file which is containing backround color.

<c:if test="check">
                    border-bottom: green ;
     </c:if>
 so that it should look like.

CASE1:
body {
             background-color: red;
		
		<c:if test="check">
                    border-bottom: green ;
                 </c:if>
             }

In this case it is working fine[It is able to apply backgound color].
but if you swap background color as shown below in CASE2. It stops working.

CASE2:
body {
             <c:if test="check">
                    border-bottom: green ;
                 </c:if>
		background-color: lime;
             }


The problem is in CSSStructuredDocumentReparser.java file where it is not parsing correctly.Parser only considers node when it gets ";" character (semicolon).

It is working fine in the CASE1 shown above because it is able to parse  background-color: red when it gets ";" and considers it as one node.

In CASE2 it is not able to parse the background color so it considers  

<c:if test="check"> border-bottom: green  as a one node and 

</c:if> background-color: red  as a second node.Instead of this it should be able to parse this as a background-color: red for applying styles.


CASE3:
body {
      
	<c:if test="check">
                    border-bottom: green ;
                 </c:if> ;

       background-color: red;
		
             }


If you add ";" in front of </c:if> [as case3]it will start working.Because now it will consider 
<c:if test="check"> border-bottom: green [one node] 
</c:if> [second node]
background-color: red [third node] // it will apply styles to current file
 

This defect is blocking RAD's functionalities so could you please fix it as soon as possible.
Comment 11 Nitin Dahyabhai CLA 2008-08-06 11:25:00 EDT
Chander, please open a *seperate* bug for this new problem.  It is not the same as the original.
Comment 12 Nick Sandonato CLA 2008-08-19 15:22:32 EDT
Verified in 3.0.1-20080818032401.