2009-07-08 31 views
3

Haben Tags innerhalb eines JSTL-Tags schlechte Form? So zum Beispiel weiß ich, dass das Folgende funktioniert, aber ist es als schlechte Form, die Skript-Tags innerhalb meiner JSTL-Tags in meinem JSP zu haben?JSTL und Javascript

<c:choose> 
    <c:when test="${!empty bean.value}"> 
    <p>Its not empty</p> 
    </c:when> 
    <c:otherwise> 
    **<script> 
     callJSSomeFunction(); 
    </script>** 
    </c:otherwise> 
</c:choose> 

Antwort

4

Ich weiß nicht, über schlechte Form (ein bisschen hart), aber sie könnte, dass jemand sehen Ihre Seite ohne JS betrachten aktiviert Ihre <c:otherwise> wird effektiv Ausgang nichts, und das ist nicht sehr anmutig.

Wenn die Seite inkrementell gerendert wird, wird der Funktionsaufruf möglicherweise so ausgeführt, wie er ausgegeben wurde, und bevor das DOM vollständig vom Browser geladen wurde und sich unvorhersehbar verhält (oder einfach nicht funktioniert - ich hatte Dies geschieht).

Ich würde in Erwägung ziehen, alle Funktionsaufrufe in den Kopf zu setzen und einen der vielen verfügbaren Tricks zu verwenden, um zu erkennen, wann das DOM geladen hat (jQuery's $(document).ready() for example), um eine bessere Trennung zu erzwingen und dein Leben so viel einfacher zu machen.

2

Ich glaube nicht - das ist, wie Sie bedingt Dinge in JSTL tun, ich glaube nicht, dass Sie nur einen Skript-Tag haben sollten, einen haben.

1

Ich habe gerade mit einigen großen JSTL Terds im Punchbowl zu tun, also dachte ich, ich würde ein paar UI-Dev-Perspektiven in den Mix werfen.

SGM-ähnliche Syntax, die eine andere Domäne der SGM-ähnlichen Syntax umhüllt, ist eine schreckliche Form, im Allgemeinen, aber das ist nicht Ihre Schuld. Sie können helfen, es besser zu machen, indem Sie sie getrennt halten. Dies ist nicht immer möglich, aber je mehr Sie vars setzen und sie nur bei Bedarf in HTML einfügen können, desto besser. Das andere Problem ist, dass Sie versuchen, clientseitige Skripte direkt mit serverseitigem Code zu starten, und ich würde sagen, ja, angesichts meiner fünfjährigen Erfahrung beim Umgang mit UI-Code, dass es ein großer PITA ist Ihre Benutzer auf der Benutzeroberfläche stoßen plötzlich auf Trigger, von denen sie nicht wirklich wissen, wie sie dem Ursprung folgen sollen und keine Kontrolle darüber haben. Hölle, löst aus, dass sogar Java-Entwickler nicht unbedingt sicher sind, wie man zum Ursprung zurückkommt, wenn die Dinge hässlich genug sind.

Stellen Sie sich vor, in unseren Schuhen zu sein. Nehmen Sie eine serviceorientierte Architektur, aber lassen Sie uns Java-Zeichenfolgen in den Param-Mix einfügen, mit denen wir tatsächlich Objektmethodenaufrufe von der Client-Seite her einrichten können. Ist das eine gute Idee? Nein, es ist eine schreckliche Idee. Nicht, weil Sie nicht wollen, dass JavaScript-Entwickler Java schreiben (Sie tun es nicht - es macht uns wirklich unangenehm), aber weil an diesen beiden Punkten der Trennung die Dinge so einfach wie möglich sein sollten. Ich sende Ihnen Daten, Sie können damit umgehen, wie Sie wollen.

So einfach uns Daten schon übergeben. Idealerweise in JSON-Form, aber wir werden uns alles gefallen lassen, damit die JS-Ausführung nicht vom Server bestimmt wird. Das letzte, was Sie wollen, ist eine Häufung von UI-Hufen in Ihren OOP-Mörderbohnen-gefüllten Weiden, also zwingen Sie uns nicht zu suchen, was der Mist fest zwischen Punkten auf beiden Seiten der HTTP-Wand ohne Grund gebunden wurde hat mir immer einen Sinn gemacht. Wir wickeln Nachrichten um Steine ​​und werfen sie über die Mauer. Das hört sich unelegant an, aber keine "Thin-Client" -Lösung hat meiner Erfahrung nach jemals weniger Schmerzen verursacht.

Vertraue deinen "ick" Instinkten. Manchmal liegen sie falsch, aber du solltest das morgens unter der Dusche herausfinden, wenn du noch darüber nachdenkst, weil sie normalerweise recht haben.