# JSP visibility scopes



## gex (7. Jan 2008)

hallo zusammen

wir migrieren gerade eine struts webapplikation von websphere 5 (j2ee 1.3) auf websphere 6.1 (j2ee 1.4).
neu nutzen wir demnach ibm rational application developer 7.

bei der jsp-validierung haben wir nun so 1-2 probleme. 
das grösste problem ist jedoch folgendes (abgekürzt):


```
<nested:match property="prop1.prop2" value="true">
<% boolean toggle=false; %>
<nested:iterate property="object1.collection1" >
<% toggle=!toggle;String farbe=toggle?"#e0e0e0":"#CCCCCC"; %>
  <tr bgcolor="<%=farbe%>"> 
	...
  </tr>
</nested:iterate>
</table>
</nested:match>

<nested:match property="prop1.prop3" value="true">
<% boolean toggle=false; %>
<nested:iterate property="object1.collection1" >
<% toggle=!toggle;String farbe=toggle?"#e0e0e0":"#CCCCCC"; %>
  <tr bgcolor="<%=farbe%>"> 
	...
  </tr>
</nested:iterate>
</table>
</nested:match>
```

dabei geht es darum, über 2 collection zu iterieren, falls vorhanden, und zeilenweise in einer tabelle auszugeben.
jede jede 2. zeile erhält dann eine andere background-color.

ist nicht schön gemacht und schon uralt, aber eben relativ oft so implementiert.

*nun zum problem: *
beim zweiten block gibt er 'Duplicate local variable toggle' und 'Duplicate local variable farbe' an.
zur laufzeit funktioniert das ganze aber.

*zur frage*
wie ist die sichtbarkeit in diesem beispiel geregelt? werden die errors berechtigterweise angezeigt (kennt jemand die spezifikation dazu), oder ist dies allenfalls ein bug in der implementierung (eventuell im zusammenhang mit den taglibs?).

besten dank für eure hilfe


----------



## byte (7. Jan 2008)

Das Scope geht IIRC über die gesamte JSP. Aber warum überhaupt Scriplets benutzen? Ist eigentlich verpönt. 

Warum nicht z.B. so:


```
<c:forEach ...>
   <c:set scope="page" var="i" value="${ i+1 }" />
   <tr style="background: ${ i % 2 == 0 ? '#EEE' : '#FFF' };">...</tr>
   ...
</c:forEach>
```


----------



## gex (7. Jan 2008)

> Das Scope geht IIRC über die gesamte JSP


deiner meinung nach ist der error also berechtigt? bei der umwandlung der jsp in den javasource ist jedenfalls 
kein spur mehr von duplicate, deshalb ergab sich die frage. unter ibm wsad5 war wohl die validierung noch nicht ganz
so tief.



> Aber warum überhaupt Scriplets benutzen? Ist eigentlich verpönt.


wie ich schon erwähnt habe weiss ich, dass das nicht schön ist, aber wer kennt es nicht, alte sourcen...
aber ich habs nicht verbrochen :lol: 

ja wir müssen das dann wohl umschreiben... :gaen:


----------



## maki (7. Jan 2008)

> bei der umwandlung der jsp in den javasource ist jedenfalls
> kein spur mehr von duplicate, deshalb ergab sich die frage.


Würde auch auf einen Fehler im Validator tippen, vor allem wenn der Compiler nicht meckert


----------



## gex (7. Jan 2008)

ich bin betreffend dem scope noch immer nicht 100% überzeugt, aber die scriptlets sind eh nicht schön un werden wohl dann ersetzt.


----------



## maki (7. Jan 2008)

Sieh dir doch das erzeugte Servlet im Java Quellcode an, da wird sich dann zeigen was draus wird.


----------



## gex (7. Jan 2008)

ju hab ich auch schon gemacht - sind eigentlich 2 fast identische blöcke (habs wieder aus nötigste gekürzt)


```
int _jspx_eval_nested_match_0 = _jspx_th_nested_match_0.doStartTag();
								if (_jspx_eval_nested_match_0 != javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
									do {
										boolean toggle = false;
										out.write("\r\n");

										org.apache.struts.taglib.nested.logic.NestedIterateTag _jspx_th_nested_iterate_0 = new org.apache.struts.taglib.nested.logic.NestedIterateTag();
										_jspx_th_nested_iterate_0.setPageContext(pageContext);
										_jspx_th_nested_iterate_0.setParent(_jspx_th_nested_match_0);
										_jspx_th_nested_iterate_0.setProperty("printWagen.printWagensBinnen");
										_jspxTagObjects.push(_jspx_th_nested_iterate_0);
										int _jspx_eval_nested_iterate_0 = _jspx_th_nested_iterate_0.doStartTag();
										if (_jspx_eval_nested_iterate_0 != javax.servlet.jsp.tagext.Tag.SKIP_BODY) {
											try {
												if (_jspx_eval_nested_iterate_0 != javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE) {
													out = pageContext.pushBody();
													_jspx_th_nested_iterate_0.setBodyContent((javax.servlet.jsp.tagext.BodyContent) out);
													_jspx_th_nested_iterate_0.doInitBody();
												}
												do {
													toggle = !toggle;
													String farbe = toggle ? "#e0e0e0" : "#CCCCCC";
													out.write("\r\n  <tr bgcolor=\"");

													out.print(farbe);
													out.write("\"> \r\n\t<td>");

													// end
												} while (_jspx_th_nested_iterate_0.doAfterBody() == javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN);
											} finally {
												if (_jspx_eval_nested_iterate_0 != javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE)
													out = pageContext.popBody();
											}
										}
										if (_jspx_th_nested_iterate_0.doEndTag() == javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
											return;
										((javax.servlet.jsp.tagext.Tag) _jspxTagObjects.pop()).release();
									} while (_jspx_th_nested_match_0.doAfterBody() == javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN);
								}
								if (_jspx_th_nested_match_0.doEndTag() == javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
									return;
								((javax.servlet.jsp.tagext.Tag) _jspxTagObjects.pop()).release();
```

von da her ist kein konflikt da, aber ob die validierung gemäss jsp spezifikation korrekt ist, würde mich schon interessieren, evtl. hängt das damit zusammen, dass die implementation der jeweiligen tags nicht klar ist.


----------

