JSP visibility scopes

Status
Nicht offen für weitere Antworten.

gex

Bekanntes Mitglied
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):

Code:
<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

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

Warum nicht z.B. so:

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

gex

Bekanntes Mitglied
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:
 
M

maki

Gast
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

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

maki

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

gex

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

Code:
								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.
 
Status
Nicht offen für weitere Antworten.

Neue Themen


Oben