Kategorie: Code-Schnipsel

Globaler Seitentitel mit ASP.NET MVC

Der Onlineversand Nerd Pizza besitzt ein in ASP.NET MVC entwickeltes Bestellsystem. Grundsätzlich sind die Pizzabäcker auch zufrieden, eine kosmetische Änderung möchten sie aber gerne noch erledigt haben. Momentan finden sich auf jeder Seite des Bestellsystems individuelle Seitentitel: Pizza bestellen, Bezahlmethode auswählen, etc. Im Sinne der Coporate Identity soll nun vor jedem dieser Titel noch “Nerd Pizza – “ stehen.

Eigentlich sollte das einfach zu lösen sein: Vor dem Platzhalter-Tag in der Masterseite fügen wir den globalen Seitentitel hinzu und schon sollte die Seite so gerendert werden wie gewünscht.

<title>
  Nerd Pizza -
  <asp:ContentPlaceHolder ID="TitleContent" runat="server" />
</title>

Doch leider fehlen in der ausgelieferten Webseite die Worte “Nerd Pizza”. EIn Blick in den HTML-Code zeigt uns nur den eigentlichen Titel der Seite:

<title>
  Pizza bestellen
</title>

Die Lösung lautet in diesem Falle ein asp:Literal-Tag zu verwenden. Folgendes in der Masterpage

<title>
  <asp:Literal runat="server" Text="Nerd Pizza - " />
  <asp:ContentPlaceHolder ID="TitleContent" runat="server" />
</title>

führt zum gewünschten HTML-Code:

<title>
  Nerd Pizza - Pizza bestellen
</title>

Problem gelöst, Zeit die Bestellfunktion ausgiebig zu testen. :)

Wie komm ich denn jetzt hier zu meiner Klasse…?

Die automatische Generierung von Klassen aus einem Webinterface-XML-Schema ist an sich eine praktische Sache.

Schön ist das im Visual Studio 2010 gelöst:
Möchte man sich zum Beispiel in vb.net eine individuelle Schnittstelle zur http.net-API schreiben, fügt man die wsdl-URI der API einfach als Service Reference ein und kann dann unkompliziert die importierten Methoden im eigenen Code benutzen.

Möchte man ein ähnlich bequemes Verfahren nun auch in Java nutzen, benutzt selbst aber aus Prinzip, fehlenden Adminrechten am eigenen Computer, Kostengründen oder in der Konsequenz ähnlich gearteten Gründen einen simplen Editor statt einer funktionsbeladenen Entwicklungsumgebung, ist es nötig sich extern eine Lösung zu suchen.

Wenn man bisher nichts mit SOAP zu tun hatte, sollte man beispielsweise Axis von vorneherein ausschließen, oder wenigstens davon absehen, sich den “dos-and don’ts”-ähnlichen Artikel auf der Apacheseite durchzulesen, denn spätestens mit Hinweisen wie “If you don’t know them, Axis is a dangerous place to learn”, vergeht einem dann doch das letzte bisschen Experimentierfreude.

Weitere Ergebnisse auf einer populären Suchmaschine der eigenen Wahl fordern etliche Foren zu Tage, in denen Personen von Personen berichten, die irgendwann mal irgendetwas mit einem Webservice und Java, unter Umständen sogar etwas mit SOAP getan haben sollen…

Nunja, die Lösung liegt dann doch schon von Anfang an auf dem eigenen Computer, zumindest bei installiertem JDK, und zwar in Form des Tools “wsimport”. In der cmd namentlich aufgerufen, unter Angabe von Zielpfad (-d) und URI… passiert vorerst leider auch dort nicht das Gewünschte, aber immerhin gibt es einige Fehlermeldungen. Diese wiederum führen zu weiteren Foren, in denen schließlich eine Option “-B-XautoNameResolution” erwähnt wird.

-B weißt dabei auf die nachfolgende Methode hin, die wsimport dazu zwingt, Variablennamen nicht nach den geltenden Konventionen umzuformen, denn dadurch können Namensdoppelungen entstehen, die oben erwähnte Fehlermeldungen verursachen. (Nachzulesen auch unter https://jaxb.dev.java.net/issues/show_bug.cgi?id=314)

Mit der Funktion -extension unterbindet man anschließend lästige Warnungen, begründet in der Ignorierung der Konventionen, -keep erstellt neben .class auch .java Dateien und mit -p bietet sich die Möglichkeit, einen Package-Namen anzulegen.
Zusammengefasst sieht das dann folgendermaßen aus:

wsimport -d [Zielordner] [API-URI] -B-XautoNameResolution -extension -keep -p [Package]

Bemerkt sei noch, dass die Lösung wesentlich leichter zu finden war als im Nachhinein die Erklärung, was denn nun eigentlich das Problem war.

Internet Explorer und der “div”-Tag

Vor kurzem stand ich vor folgendem Szenario bei der Entwicklung mit ASP.NET MVC und JQuery:

Ich hatte eine Website erstellt, die dynamisch Inhalte vom Server nachgeladen hat. Gut, werden sich jetzt einige denken, das ist doch inzwischen Standard und sollte keine Probleme bereiten. Für gewöhnlich ist dies auch so, jedoch gab es hier eine Ausnahme: den Internet Explorer.

Man denke sich folgenden vereinfachten Quellcodeabschnitt:

<input type="text" onchange="$.get("/myController/Search",
   {query :  $(this).val()},
   function (resultValue)
   { $('#result_placeholder').html(resultValue); }  />
<div id="result_placeholder" />
<input type="submit" value="Suche starten" />

Mit eigenen Worten beschrieben: Gibt man etwas in das Textfeld ein, wird eine Anfrage mit dem Inhalt der Textbox an den Server gesendet und Resultate in das div mit der Id result_placeholder hineingeschrieben.

Das klappte auch wunderbar. Jedoch war daraufhin mein “Suche starten”-Knopf verschwunden und ich konnte mir nicht erklären warum. Durch eine Analyse des zur Laufzeit vorliegenden Quelltextes konnte ich dann auch sehen, dass mein Submit-Button tatsächlich nicht mehr vorhanden war. Es stellte sich mir also die Frage, wieso er im Internet Explorer verschwand und in allen anderen Browsern weiterhin vorhanden war.

Die Lösung des Ganzen ist relativ einfach. Anstatt <div id=”result_placeholder” /> schreibt man <div id=”result_placeholder”></div> in den Quelltext, dann wird der Inhalt richtig gesetzt und auch der “Suche starten”-Button ist weiterhin vorhanden. :-)

Edit:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd“>
<html xmlns=”http://www.w3.org/1999/xhtml“>

Diesen DOCTYPE verwende ich bei dem oben genannten Problem. Laut W3C ist damit das Dokument als XHTML ausgezeichnet und mein “<div />” standardmäßig erlaubt. In dem Zusammenhang ist auch meine Beobachtung zu betrachten.