Die Woche vor dem Urlaub ist immer ein bisschen stressig. Von daher gibt es heute nur 2 Links:
Über die Woche verteilt, gibt es immer wieder interessante Artikel im Netz für mich, die mir ein Lesezeichen bei delicious.com wert sind. Einige sind der Anstoß für einen Beitrag in meinem eigenen Blog, die meisten aber gesammeltes Wissen (wir alle sind Jäger und Sammler), das zum Abruf bereit steht.
Diese Woche haben es folgende Artikel in meine Linkliste geschafft:
Seit vorgestern steht der erste Release Candidate vom Spring Framework zum Download bereit.
In dieser Version werden erstmalig der JSR-303 (Bean Validation) und JSR-330 (Dependency Injection in Java) unterstützt. Besonders auf die Umsetzung der Bean Validation war ich gespannt, denn dadurch kann man über Annotations seine Beans mit Constraints versehen.
1. annotieren der Bean
1 2 3 4 5 6 7 | public class Event { int id; @NotNull @Size(min=1,max=50) String description; ... |
Durch die zwei Annotations (in validation-api-1.0.CR3.jar enthalten) wird festgelegt, dass der Wert für das Attribut description nicht null sein darf und minimum 1 Zeichen aber maximal 50 Zeichen enthalten muss.
2. validieren der Bean innerhalb des Controllers
Zur Validierung benötigt man eine Implementierung des JSR-303, wie z.B. den Hibernate Validator (momentan in Version 4.0.0 CR1). Der hat allerdings eine Menge Abhängigkeiten und muss erst über Maven kompiliert werden.
Hat man diese Hürde genommen (und hat die daraus resultierende Jar Datei in sein Projekt eingebunden), benötigt man noch folgende Bibliotheken um keine Runtime Fehler zu produzieren:
diese liegen dann aber sowieso im lokalen Maven Repository vor.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | @RequestMapping(value="/event/save", method=RequestMethod.POST) public String save(Event event,BindingResult bindingResult, Model model) { LocalValidatorFactoryBean validator = new LocalValidatorFactoryBean(); validator.setProviderClass(HibernateValidationProvider.class); validator.afterPropertiesSet(); validator.validate(event,bindingResult); if (!bindingResult.hasErrors()) { // save ... model.addAttribute("message", "update successfully"); } else { for (FieldError e : bindingResult.getFieldErrors()) { log.warn(e.getField()+": "+e.getDefaultMessage()); } model.addAttribute("errors", bindingResult.getFieldErrors()); } model.addAttribute("event", event); return "update"; } |
In den Zeilen 3-5 Wird eine Instanz des Hibernate Validators erzeugt. In Zeile 7 wird dann endlich validiert. Ob bei der Validierung Fehler aufgetreten sind kann man mit der Methode hasErrors() überprüfen (Zeile 9). Zugriff auf alle Fehler (z.B. zum Loggen) erhält man über die Methode getFieldErrors() (Zeile 13-15).
In Zeile 16 werden die Fehler der View übergeben.
3. Ausgabe der Fehler in der View
Zur Ausgabe der Fehler wird die JSP Standard Tag Library verwendet.
1 2 3 4 5 6 7 8 | <p>${message}</p>
<c:if test="${!empty errors}">
<ul>
<c:forEach var="error" items="${errors}">
<li>${error.field}: ${error.defaultMessage}</li>
</c:forEach>
</ul>
</c:if> |
Es ist noch gar nicht so lange her, da wurde JavaScript aufgrund seiner Browser Inkombatibilitäten und Sicherheitsbedenken von vielen verteufelt.
Erst mit Ajax (Asynchronous JavaScript and XML) und den darum entstandenen Frameworks (die die Browserinkompatibilitäte abfangen) ist es zum Lieblingskind und “must have” der Webentwicklung geworden.
Doch zwischen den Frameworks gibt es teilweise erhebliche Unterschiede. Das gilt nicht nur für den Funktionsumfang, sondern auch für die Größe und Ausführungsgeschwindigkeit.
Matthias Schütz hat mit seiner Ajax Framework Matrix versucht, die Eigenschaften der Ajax Frameworks in einer Übersicht zusammenzuführen, um sie so besser vergleichen zu können. Dass ist ihm nicht nur gut gelungen, sondern ist auch noch schön anzusehen.
In der Matrix sind auch die Links zu den Frameworks, deren Dokumentation und einigen Beispielen enthalten.
Fazit:
Die Matrix erleichtert wirklich den Vergleich zwischen den einzelnen Ajax Frameworks. Eines leistet die Matrix allerdings nicht.
Eine Entscheidung für eines der Frameworks muss man leider immer noch selbst treffen, nur der Weg dorthin wird unterstützt.
Grails Anwendungen im Internet zu deployen ist gar nicht so einfach. Nicht jeder hat einen virtuellen oder root Server um dort einen Java Applikationsserver (wie Tomcat oder Jetty) laufen zu lassen.
Provider für das Hosting von PHP Anwendungen, gibt es wie Sand am Meer. Möchte man Java Applikationen gehostet bekommen, vermindert sich die Anzahl der potentiellen Kandidaten schon drastisch. Möchte man dann noch Grails Anwendungen deployen und das am besten noch kostenlos, kann man die Provider, die dieses anbieten, an einer Hand abzählen.
Eine Liste von Providern, bei denen man Grails Anwendungen deployen kann, wird in der Dokumentation von Grails gepflegt.
Die 3 Provider, die momentan einen kostenlosen Trial oder Developer Account anbieten, sind:
Während die ersten beiden einen kostenlosen Trial Account anbieten, gibt es bei Morph AppSpace für Entwickler einen kostenlosen Developer Account.
Meine kleine Grails Anwendung grum läuft auch bei Morph Apps und es war erstaunlich einfach sie dort zu deployen.
Grundsätzlich hat man bei Morph AppSpace die Wahl zwischen einer PostgreSQL und einer MySql Datenbank. Als Applikationsserver kommt Jetty zum Einsatz.
Schon bei der Registrierung wird die Datenbank angelegt und Jetty konfiguriert. Das einzige was man selbst noch machen muss, ist die Datenbankkonfiguration in die Datei DataSources.groovy einzutragen und das Web Archiv (erstellen mit grails war) mittels der zur Verfügung gestellten Java Bibliothek oder dem Ant Task auf Morph Apps hochzuladen. Fertig.
Bei dem kostenlosen Developer Account, muss die Anwendung allerdings innerhalb von 31 Tagen erneut deployed werden. Geschieht das nicht, wird die Applikation offline gesetzt und nach weiteren 31 Tagen wird der Webspace freigegeben.
Update:
Morph AppSpace bietet momentan leider keinen kostenlosen Developer Account mehr an. So wird auch meine kleine Applikation Grum nicht mehr bei Morph AppSpace gehostet. Ich werde mir mal die Google App Engine anschauen. Dafür dürften aber ein paar kleine Änderungen notwendig sein (z.B. JPA statt Hibernate für die Persistenz). Wenn es soweit ist, werde ich meine Erfahrungen natürlich hier in meinem Blog schildern.
Resourcen:
Liste der Provider für das Hosten von Grails Anwendungen
Grum bei Morph AppSpace
