Author: Michael Müller

NetBeans contribution

Everybody has the ability to influence an open source project. All you have to do is to contribute. Not only source code, but bug reports, suggested enhancements etc.

Today I got this mail from the NetBeans team. And was astonished how much it had been for just one version. And ther is still more, targeted for NetBeans 7.2 version. Let’s go on 😉

 

Dear NetBeans User,

In the past you have taken the time to report issues that you encountered while using NetBeans software. A new version (NetBeans 7.1) has just been released,and we’d like to inform you that the following issue(s) you reported have been addressed in the new release: Continue reading “NetBeans contribution”

NetBeans 7.1 and more

I blogged last article apx. 2 month ago. I announced an application which shall maintain my book list. At this time, the NetCAT game startet: Community members were requestes to test the upcomming version. It took a lot of my time and I could discover some bugs which had been fixed and could contribute some ideas for enhancements, especially for web development. Thanks to the NetBeans team, but also the community and the NetCAT team, the upcomming version contains richer functionality and gets more and more “round” due to little but helpful details.
The NetCat game is over now. NetBeans 7.1 will be published soon. And me, I’m going to continue on the announced project, as well as writing reviews and articles…

NetBeans 7.1 und mehr

Nun, mein letzter Artikel ist inzwischen rund zwei Monate alt. Darin habe ich eine Applikation zur Verwaltung meiner Rezensionen angekündigt. Daran habe ich zwar gearbeitet – aber nur sehr wenig. Denn so ungefähr zu diesem Zeitpunkt startete NetCAT, das Test-Programm zur kommenden Version von NetBeans. Und so habe einige Zeit damit verbracht, die neue Version zu prüfen. Dabei konnte ich diverse Fehler entdecken, die im Laufe der Entwicklung behoben wurden. Aber auch einige Ideen für Erweiterungen beisteuern, insbesondere im Bereich Editorinfrastruktur für Web-Applikationen. Dank der großartigen Arbeit des NetBeans-Teams sowie zahlreicher Communitiy-Mitglieder, insbesondere der NetCAT-Teilnehmer, bietet die kommende Version diverse neue Funktionen und wurde in vielen Details “runder”. NetBeans 7.1 wird in wenigen Tagen verfügbar sein.
NetCAT ist beendet – und so setze ich nun verstärkt meine Arbeit an der Buch-Applikation fort. Sie wird künftig in mein Tutorials einfließen. Und dann muss ich noch ein paar Rezensionen und Artikel schreiben…

Tutorial web development (with JSF): Application “BookReview”, Part I

In my blog, I publish a list of those books, I wrote a review for. Every book will be displayed in a table with this information:

  • Title
  • Subtitle
  • Author(s)
  • Publisher
  • Year
  • Language
  • ISBN
  • Short text
  • Reference to my rewiew

These information is written manually and has to be maintained for every category and language. Changing the layout (if more than just CSS) will be a huge effort.

Now, I want to develop a multiligual application for publishing my booklist in an easy manner. One goal is to publish this information from a single soure in diverse categories and / or languages. Every book should be listet in the appropriate category just by assigning this category. The layout may change and should be maintained at a central place to be used for all books.
Continue reading “Tutorial web development (with JSF): Application “BookReview”, Part I”

Tutorial Webentwicklung (mit JSF) – Applikation “Rezensionen”, Teil I

In meinem Blog liste ich u.a. die von mir rezensierten Bücher. Dabei wird jedes Buch in tabellarischer Form aufgeführt.

Zu jedem Buch werden diese Informationen dargestellt:

  • Titel
  • Untertitel
  • Autor(en)
  • Verlag
  • Jahr
  • Sprache
  • ISBN
  • Kurztext
  • Verweis auf die Rezension(en)

Die Pflege erfolgt manuell und muss in jeder Kategorie bzw. Anzeigesprache eigens erstellt werden. Eine Änderung der Darstellung ist mit hohem Aufwand verbunden.

Es soll nun eine mehrsprachige Anwendung zur Darstellung der rezensierten Bücher entwickelt werden. Ziel ist, die Bücher in unterschiedlichen Anzeigesprachen sowie in unterschiedlichen Kategorien darzustellen. Dabei soll ein Buch durch Zufügen einer Kategorie in derselben gelistet werden. Die Darstellung selbst soll austauschbar gestaltet werden. Sie wird an zentraler Stelle gepflegt und automatisch für alle Bücher genutzt.
Continue reading “Tutorial Webentwicklung (mit JSF) – Applikation “Rezensionen”, Teil I”

GlassFish behind Apache HTTP Server

You may have developed a web application using JSF or other techniques, wich runs on an application server and should be reachable from the internet. You might configure your AppServer, e.g. GlassFish, listening on port 80 directly. Usually it is better to run this behind a HTTP server, which serves static content or provides load balancing. The folowing configuration is an example how to run GlassFish behind an Apach WebServer.

Its using this scenario:

  • The application runs on localhost:8080/myapp
  • The site is reachable on http://mydomain.net
  • The site is hosted on a virtual server
  • The complete site is forwared to the AppServer
  • The modules mod_proxy.so and mod_proxy_http.so are loaded
<VirtualHost *:80>
   ServerName mydomain.net
   ServerAlias www.mydomain.net

   ServerAdmin webmaster@mydomain.net
   DocumentRoot /var/htdocs/mydomain/

   <Directory /var/htdocs/mydomain/>
       Options Indexes FollowSymLinks MultiViews
       AllowOverride None
       Order allow,deny
       allow from all
   </Directory>

  ProxyRequests Off

  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>

  ProxyPass /myapp http://localhost:8080/myapp/
  ProxyPassReverse /myapp http://localhost:8080/myapp/

</VirtualHost>

Essential is the config of ProxyPass(Reverse), which forwards the directory (“/myapp”) to the adress of your AppServer (“http://localhost:8080/myapp/”). Please treat this only as an example. For security reasons you may run Apache within your dmz and GlassFish on a different machine behind your firewall.

Maybe I provide a full commented description later on in an future article of my JSF tutorial.

 

To web development content.

GlassFish hinter Apache HTTP Server

Haben Sie eine Applikation mittels JSF oder anderen Techniken auf einem Applikationsserver, z. B. GlassFish, erstellt und soll diese vom Internet erreichbar sein, so können Sie natürlich den AppServer direkt an Port 80 lauschen lassen. Oft aber ist es sinnvoll, einen HTTP-Server vorzuschalten, der sich dann um Lastverteilung oder bereitstellung statischer Seiten kümmern kann.

Das folgende Beispiel zeigt, wie Sie GlassFish hinter einem Apache WebServer betreiben. Dem Beispiel liegt dieses Szenario zugrunde:

  • Die Applikation läuft unter localhost:8080/myapp
  • Die Site unter http://mydomain.net erreichbar
  • Die Site wird als virtueller Server gehostet
  • Das Verzeichnis /myapp wird auf den AppServer geleitet
  • Die Module mod_proxy.so und mod_proxy_http.so sind geladen
<VirtualHost *:80>
   ServerName mydomain.net
   ServerAlias www.mydomain.net

   ServerAdmin webmaster@mydomain.net
   DocumentRoot /var/htdocs/mydomain/

   <Directory /var/htdocs/mydomain/>
       Options Indexes FollowSymLinks MultiViews
       AllowOverride None
       Order allow,deny
       allow from all
   </Directory>

  ProxyRequests Off

  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>

  ProxyPass /myapp http://localhost:8080/myapp/
  ProxyPassReverse /myapp http://localhost:8080/myapp/

</VirtualHost>

Die vorliegende Konfiguration zeigt kurz, wie dies für den Apache2 konfiguriert wird. Entscheidend sind hier die Einträge unter ProxyPass(Reverse), welche das Verzeicnis (“/myapp”) auf die lokale Adresse des AppServers (“http://localhost:8080/myapp/”) umleiten. Betrachten Sie dies nur als ein Beispiel. Im Produktivbetrieb ist es aus Sicherheitsgründen ratsam, den Apache-Server in der DMZ und den GlassFish auf einer anderen Maschine hinter der Firewall zu betreiben.

Eine ausführlichere Beschreibung erfolgt möglicherweise später im Rahmen meines Tutorials.

 

JSF, Pflichfelder markieren

Kennen Sie dies nicht? Sie haben eine Applikation mit diversen Dialogen, in denen jeweils sowohl Pflicht- als auch optionale Felder enthalten sind. Damit diese beiden Typen für den Anwender unterscheidbar sind, sollen die Pflichfelder markiert werden. Und dass ganze an einer zentralen Stelle, z.B. als Teil eines Templates. Die dahinter liegende Idee ist recht einfach: Vor der Auslieferung an den Browser werden alle Label geprüft, ob die zugehörigen Eingabefelder Pflicht sind. Falls ja, erfolgt die Markierung. Continue reading “JSF, Pflichfelder markieren”

JSF, mark required fields

Don’t you know this: You have an application using some dialogs and each dialog contains some required fields and some, whiche are not mandatory. To disinguish these two kinds of fields, the required fields should be marked, e.g. with an asterisk. Now, what we want to do, is to write a central function which might be used in all pages. The idea is quite simple: Before rendereing, check all labels and theis associated input components. If the input is required, mark it. Continue reading “JSF, mark required fields”

Tutorial Webentwicklung (mit JSF) VII: Backstage

Backstage

[Dieser Artikel ist noch in Bearbeitung und daher unvollständig]

Bei einer traditionellen Anwendung ist es in der Regel so, dass die Applikation selbst für die Darstellung verantwortlich ist. Auch wenn Sie dafür eines Severdienstes wie X bedienen sollte, so obliegt die Steuerung dennoch dem Programm.

Anders bei einer Webapplikation. Hier werden die Daten an einen Browser übergeben, der sich um die Darstellung kümmert. Dazu verpackt der Server den darzustellenden Inhalt in ein (X)HTML-Dokument. Daneben kann der Server noch ein paar Darstellungsinformationen in Form von CSS mitliefern. Alles Weitere ist dann Sache des Browsers. Und so wie es unterschiedliche Browser gibt, kann sich auch die Darstellung unterscheiden. Die stetige Weiterentwicklung der Standards sorgt hier glücklicherweise für eine allmähliche Angleichung. Hält hier der Anwender aber ein lokales CSS vor, so kann die Darstellung wieder anders ausfallen.

Nicht nur, dass eine Webapplikation die Ausgabe an den Browser delegiert; sie wird auch nicht von selbst aktiv! Erst wenn der Anwender via Browser eine Seite anfordert, so liefert die Applikation eine solche aus. Die (scheinbar) aktive Änderung von Inhalten aufgrund von severseitiger Verarbeitung geht nicht ohne weitere Hilfsmittel. Hier lautet das Stichwort AJAX (Asynchronous JavaScript and XML). Womit wir neben (X)HTML und CSS bei einer weiteren browserseitigen Technik angelangt sind: JavaScript. Der Browser fordert zwischendurch mittels JavaScript immer wieder mal mittel pertiellem Request ein paar Daten an und tauscht Teile des Browserinhalts aus. Somit entsteht zumindest zum Teil der Eindruck, der Server aktualisiere den Bildschirm. Tatsächlich geht hier aber immer wieder eine Anfrage vom Client aus (pull). Ein echtes Push, also die vom Server veranlasste aktive Änderung der Darstellung erfordert einen tieferen Griff in die Trickkiste. Hier wird die Antwort an den Client künstlich verzögert, um zu einem späteren noch Informationen übermitteln zu können. Doch dies ist etwas für einen späteren Teil.

Bei einer traditionellen Applikation kann das Programm sofort auf eine Anwendereingabe reagieren. Bei einer Webapplikation bekommt das Programm erst dann etwas von den Anwendereingaben mit, wenn eine neue Seite oder – meist in Verbindung mit AJAX – patriell eine neue Seite angefordert wird. Zu diesem Zeitpunkt können bereits Eingaben in diversen Feldern erfolgt sein. Nicht schwer vorzustellen, dass die Applikation hiermit etwas anders umgehen muss. An dieser Stelle unterstützt JSF den Anwender und löst auf dem Server für die einzelnen Eingaben entsprechende Events aus, so dass sich ein dem Entwickler nicht ganz fremdes Programmiermodell ergibt.

Und noch ein Unterschied: Eine Webapplikation läuft meist in einer Ablaufumgebung, die ihr zahlreiche Dienste zur Verfügung stellt. Eine solche Ablaufumgebung wird als Container beszeichnet, im Falle von JSF ist dies ein sogenannter Servlet-Container. Dies deutet auf die zugrunde liegende Technik der Servlets hin. Auch bei der Entwicklung mit JSF kann die direkte Nutzung von Servlets hier und da angebracht sein. Es kann also nicht schaden, wenn Sie sich auch mit dieser Technik vertraut machen. Mehr dazu in einem späteren Teil.

Der Servlet -Container versorgt die Applikation mit Schnittstellen zu anderen Diensten. Er ist Bestandteil eines Applikations- oder auch Webservers. Zahlreiche Server beinhalten im Wesentlichen einen Container und so werden die Begriffe Container und Applikationsserver häufig synonym genutzt. Tatsächlich kann ein Server jedoch mehrere Container beherrbergen. So z.B., GlassFish, der neben Dem Servlet-Container u.a. Auch einen EJB-Container beherrbergt. Im Folgenden schauen wir von außen auf den Applikationsserver.

Wenn nun ein Anwender die Web-Applikation nutzen möchte, so ruft er in seinem Browser die URL der Anwendung auf. Der Client startet eine Anfrage an den Server. Dieser erkennt anhand der URL, dass er nicht einfach eine statische Seite ausliefern muss, sondern leitet die Anfrage über den Container an die Applikation weiter. Dort wird diese verarbeitet. Die Ausgabe wird als (X)HTML-Dokument genertiert und an den Browser verschickt. Dieser zeigt die Daten an.

<Abbildung fehlt noch>

Bei dieser Sichtweise betrachten wir den ApplicationServer al BlockBox. Interessant ist aber auch, was darin passiert. Erinnern Sie sich kurz an die bisherigen Anwendungen: Hier haben Sie jeweils eine JSF-Seite definiert. Als Seitensprache wurden Facelets eingesetzt. Jede Seite bestand neben HTML auch aus bestimmten Tags, wie beispielsweise “f:InputText”. Im Browser haben jeweils die URL einer solchen Seite angegeben. Entweder direkt oder indirekt als Angabe der Applikations-URL, die aber intern auf eine konkrete Seite verwiesen hat.

Der Server bestimmt anhand der URL die darzustellende Seite, analysiert deren Inhalt und löst die Tags auf. Im einfachsten Fall werden diese durch entsprechende Daten ersetzt. Die so entstandene Seite wird an den Browser geschickt. Dies ist aber lediglich eine vereinfachte Darstellung. Der Browser könnte ja bereits vorher Daten der Aplikation angezeigt haben. Daher prüft JSF als erstes, ob bereits eine Session besteht. Falls ja wird der Komponentenbaum, die logische Abbildung der dazustellenden Inhalte, wieder hergestellt. Eingaben werden validiert und Datenfelder upgedatet. Insgesamt unterscheidet hier JSF sechs verschiedene Phasen.