Pöhler Blog

The problem occurs on a JSCookMenue, if you wish to create the NavigationItems dynamically from a backing bean and some of the menu entries should be result in the same outcome. Typically you want to distinct the selected menu entries on the selected page (target of the outcome), but this is impossible, because you can't transfer the information of the selected entry.

In case of static NavigationItems you can use an ActionListener to transfer this information into a backing bean, where you can read this information on the next page. But in case of dynamically created menuitems you havn't the possiblility to add an ActionListener , because the NavigationItem isn't a Component. Only the JSCookMenu is.

So that is the problem. The solution I found is dirty, but it works. Better approaches are welcome !

The only thing you can add to a NavigationItem is the action attribute. So I extend the action attribute from "report" to something like "report_report1" and "report_report2". Then I wrote a custom NavigationHandler that hijacks outcomes which starts with "report_" and the only Job of this NavigationHandler is to change the outcome to "report" and put the other part of the term ("report1" or "report2") into a sessionbased backingbean.

This approach is weak, because it adds a new meaning to the naming of action outcomes, but currently I doesn't found anything else working for me.

Labels: Dynamic Items, JSCookMenue, JSF

Angeregt von dem JSF Buch, habe ich angefangen meine Anwendungsstruktur zu überprüfen und festgestellt, dass da ein paar Sachen noch eleganter gelöst werden können. Die Entkopplung der Business-Objekte aus der Hibernate-Session fand nicht statt. Statt dessen habe lazy="false" relativ häufig verwendet und die Business-Objekte im Prinzip bis in die Presentation durchgereicht. Dass das langsam ist hatte ich schon bemerkt, aber dass das böse ist - das weiss ich jetzt auch ;-) Eleganter ist es DTOs (Data Transfer Object) zu bilden, die dann nur genau den Datenumfang in den Presentation-Layer bringen, der da auch gebraucht wird. Da DTOs von den Business-Objekten unabhängig sind kann man sie super serialisieren und über den Statemanager aufrechterhalten, ohne dass man in irgendwelche Schwierigkeiten mit bereits geschlossenen Hibernate-Sessions kommt. Diese DTOs zu erzeugen ist irgendwie recht aufwendig und es gibt verschiedene Wege das zu tun. Im Buch JSF@Work wird ein ObjectCloner beschrieben, der interessant klingt, sich aber einer weiteren Beurteilung entzieht solange der Beispielcode noch nicht online ist. Martin Fowler beschreibt in seinem Enterprise Patterns Buch eine Möglichkeit die DTOs mit speziellen Assembler-Klassen zu konstruieren. Je nach Anzahl der Ausprägungen mit Daten kann es dabei gerne auch mal mehr als eine Assembler-Klasse pro DTO geben. In den Java-Blueprints ist die Sache ebenfalls mit Assemblern angegeben. Deshalb habe ich mich jetzt erstmal für eine Test der Assembler-Nummer entschieden. In dem Buch von Martin Fowler ist das am besten erklärt, vor allem auch für den Fall, dass ein DTO geändert wird und dann das korrespondierende Business-Objekt die Änderungen übernehmen soll - soll ja vorkommen.

In dem Buch JSF@Work war ein zweiter interessanter Ansatz, nämlich das Erweitern von DTOs um UI-Funktionalitäten durch eine Aspect-Map. Momentan benutze ich das Dekorierer Pattern um die Business-Objekte um GUI-Funktionalitäten zu erweitern, was eigentlich ganz gut klappt. Ich glaube es ist nicht viel Arbeit die paar Funktionen in Aspekte umzulegen und werde es mal probieren.

Mal sehen wie's wird.

Labels: AspectMap, Data-Transfer-Object, Decorator, DTO, JSF

Kleiner Wehrmutstropfen: Der Link auf die Beispielanwendung aus dem Buch geht nicht. Hab' gerade diesbezüglich eine Anfrage bei irian.at laufen. Mal sehen wie schnell dort reagiert wird.

Edit: Martin Marinschek hat persönlich und ziemlich schnell reagiert und mir geantwortet. Die entsprechende Seite wird da bald online sein.

Labels: JSF, JSF-at-Work

Ich hab's ehrlich gesagt noch nicht vollständig gelesen, aber ich möchte dennoch meine Meinung über dieses Buch abgeben. Das Buch JSF@Work wurde unter der Mitwirkung führender MyFaces-Committer geschrieben und ist entsprechend fundiert. Nach den allgemeinen JSF-Grundlagen wird relativ ausführlich auf die MyFaces-Komponenten eingegangen (Für die Non-Checker: MyFaces ist eine freie Implementierung des JavaServerFaces Standards). Zu meiner Freude wurde auf AJAX und auf AJAX in Verbindung mit JSF in einem eigenen Kapitel eingegangen. Ebenfalls sehr schön fand ich die Vorstellung der Best-Practice-Beispielanwendung. Es war in weiten Teilen mit meiner Anwendungsstruktur identisch (Hibernate/Spring/JSF) und deshalb für mich sehr wertvoll. Da habe ich ein paar wertvolle Hinweise bekommen, speziell der ObjectCloner und die AspectMap verdienen einer näheren Betrachtung am heutigen Nachmittag. Das Buch ist sein Geld auf jeden Fall Wert.
Gelesen habe ich das Kapitel über die Best-Practice-Beispielanwendung in der Kapelle, das ist eine Restaurant/Kneipe im Viertel, wo ich nebenbei ein wenig gefrühstückt habe. Danach habe ich zur geistigen und körperlichen Verdauung einen Spaziergang an der Weser gemacht. Die Wiese finde ich noch ganz schön grün für Mitte Dezember, aber zumindest war es kalt.

Labels: AJAX, JSF, JSF(AT)Work