Servlet-Klassen und Templates trennen?

[deamon]

Servlet-Klassen und Templates trennen?

Hallo,

ich habe schon öfter gehört, dass man (Servlet-)Klassen und Templates in zwei parallele Verzeichnisbäume trennen sollte.

Beispiel (ausgehend von einem Maven-Archetype):

MeineAnwendung/
  src/
    main/
      resources/
        com/
          firma/
            projekt/
              HalloWelt.class
      webapp/
        WEB-INF/
          templates/
            com/
              firma/
                projekt/
                  HalloWelt.tpl

Ich frage mich jedoch ernsthaft, was der Vorteil davon sein soll. In jedem Fall hat man davon den Nachteil, dass man zwei Verzeichnisstrukturen aufbauen und pflegen muss und dass man öfter zwischen beiden hin und her wechseln muss. Außerdem finde ich das noch unübersichtlicher.

Die Alternative wäre eine Struktur für beides:

MeineAnwendung/
  src/
    main/
      resources/
        com/
          firma/
            projekt/
              HalloWelt.class
              HalloWelt.tpl

Da steht zusammen, was zusammen gehört und man muss keine zwei parallelen Verzeichnisstrukturen pflegen.

Was spricht dagegen, beides in eine Hierarchie zu packen?

 

[maki]

Du verwechselst da etwas.

In Maven kommen Java Klassen (Servlets) kommen nach [c]src/main/java[/c], andere Resourcen nach [c]src/main/resources/[/c].

Was spricht dagegen, beides in eine Hierarchie zu packen?

Ordnung und Konvention.

 

[deamon]

Achja, die Maven-Philosophie ist ja, für eine Webanwendung zwei Projekte zu machen. Finde ich irgendwie unintuitiv.

Wieso ist es unordentlich, die Templates neben die Java-Dateien zu packen? Wicket macht es auch so.

 

[mvitz]

Wicket hat diese aber auch nur in der deployten Anwendung nebeneinander. Während der Entwicklung kann man dort auch zwei Verzeichnisse benutzen.

Ich persönlich bin auch für das trennen. Sucht man nach templates weiß man wo diese zu finden sind, sucht man nach Java Klassen, findet man sie dort. So kommt niemand durcheinander und sollte man später im Buildprozess etwas mit bestimmten Dateien machen wollen, ist dies idr. auch einfacher zu bewerkstelligen.

 

[deamon]

Es scheint mir irgendwie auf eine Geschmacksfrage hinauszulaufen. Jedenfalls wüsste ich nicht, warum man die Templates schlechter finden sollte, wenn sie im gleichen Verzeichnis wie die Java-Dateien liegen. Es wird ja wohl kaum jemand ein Template mit einer Java-Datei verwechseln (allein schon wegen der Dateiendung nicht).

Die Vereinfachung des Build-Prozesses, wenn man mit bestimmten Dateien noch etwas machen will, sehe ich da schon eher als Argument. Wobei ich nicht weiß, an was du denkst. Das einzige Argument, was mir für ausgelagerte Templates einfällt, ist, dass man sie leichter komplett austauschen kann, so wie man bei manchen Blogs, Foren usw. das Aussehen durch Wechsel der Templates ändern kann.

 

[maki]

Achja, die Maven-Philosophie ist ja, für eine Webanwendung zwei Projekte zu machen. Finde ich irgendwie unintuitiv.
.

Wieso 2 Projekte?

Meinst du damit die Javaklassen komplett in ein Modul auszulagern?
Das kann man machen, muss aber nciht, wenn die Javaklassen keinen Bezug zum Web haben und wiederverwendbar sind, haben bietet es sich an.
Jedenfalls bist du bei Maven2 gut beraten dich an die Koventionen zu halten, die pom wächst sonst sehr schnell und wird unübersichtlich.

Ps: Ressourcen und Java Klassen zu trennen ist nicht erst durch Maven bekannt geworden.
Schon mal mit Hibernate ohne Annotations gearbeitet? Für die mapping Dateien ein eigenes package zu machen war üblich, da es sonst unübersichtlich wurde. Mit getrennten Ordner war das kein Problem.

 

[deamon]

Im normalen web-app-Archetype ist kein Verzeichnis für Java-Klassen vorgesehen. Allerdings scheinen die Maven-Entwickler selbst nicht besonders überzeugt von ihrem Archetype zu sein, denn sie schreiben: "If you were looking for a functional web application, this archetype is going to disappoint you." Maven Book: 16.3.Available Archetypes

Da frage ich mich: Wozu dann der Quatsch? Konventionen sind ja schön und gut, aber diese Konvention in Form eines Archetyps (der auch noch die betagte JUnit-Version 3.8 mitbringt) scheint mir nicht besonders sinnvoll zu sein. Es ist ja kein Zufall, dass es für alle möglichen Web-Frameworks eigene, umfassendere Archetyps gibt.

Ich fürchte, ich muss mir für meine Bedürfnisse einen eigenen Archetype bauen.

Aber zurück zu den Templates. Bei Hibernate habe ich die XML-Dateien auch direkte neben die Klassen gelegt, die damit beschrieben wurden. Ich fand das einfach und übersichtlich. Bei meinem aktuellen Fall stört mich an der Trennung, dass ich nicht einfach ein Template-Verzeichnis machen will, sondern die Templates in eine Verzeichnisstruktur sortieren will.

Letztlich hätte ich gerne eine Struktur, bei der man leicht Teile extrahieren kann. Wenn ich z. B. ein Paket "article" mit folgendem Inhalt hätte, könnte ich das ganze Paket leicht als Einheit in einer anderen Anwendung nutzen (so wie ja auch bei Wicket HTML und Java eine wiederverwendbare Einheit bilden).

article/
  ArticleServlet.java
  representations/
    GET.html
    GET.rss
    POST.html

 

[Noctarius]

Komisch ich komm mit dem Archetyp webapp immer gut klar. Schnell ein src/main/java Verzeichnis dazu gepackt. Maven gesagt es soll die Projekteinstellungen in Eclipse aktuallisieren und du hast dein Java Src-Dir.

Ich versteh deinen deinen Einwand nich. Das JUNit ist halt etwas älter, und? Eine Zahl im pom.xml ändern und schon ist das aktuelle drin.

Ich weiß garnicht was sich immer alle so gegen die ConventionsOverConfiguration wehren. Es macht die Sache super einfach. Im Prinzip schafft es eine komplette App aus ca 10 Zeilen pom.xml zu bestehen. Wenn mir etwas absolut nicht passt konfiguriere ich halt (und ärgere mich hinterher, dass plötzlich irgendwas den Build verhagelt).
Ist es so schwer zu akzeptieren, dass die Maven Struktur ansich sinnvoll ist? Was ist so schlimm daran Resourcen und Code zu trennen? Ist das nicht auch nur eine MVC Version oder glaubst du MVC Frameworks haben sich auch nur aus Langeweile durchgesetzt oder weil es praktisch war?

 

[deamon]

Versteh mich nicht falsch, ich finde Konventionen prinzipiell auch gut. Bloß eine Konvention, wie der web-app-Archetype, nicht vollständig ist, finde ich das halt etwas blöd. Gleiches gilt für JUnit. Warum wird da standardmäßig so eine historische Version verwendet?

MVC hatte übrigens ursprünglich einen ganz anderen Hintergrund als bei MVC-Web-Frameworks. Der Kerngedanke von MVC passt eigentlich überhaupt nicht ins Web. Ich glaube die MVC-Frameworks haben sich in erster Linie verbreitet, weil es vorher die Unsitte gab, fachlich Logik in die Views zu schreiben. Beim eigentlichen MVC ist View und Controller ziemlich dicht zusammen. Swing und Wicket mit den Ereignishandlern in den Views gehen in die Richtung. Man könnte den Controller aber auch als Dienst auffassen (im Sinne von REST) und die View als völlig unabhängig betrachten. Umgekehrt könnte man aber auch bei REST einen Controller als Resource und die Views als deren Repräsentationen betrachten und dann würde es schon wieder eng zusammen gehören. Lange Rede, kurzer Sinn: ich glaube man kann beides rechtfertigen.

 

[Noctarius]

Und wenn ich eine Webanwendung rein in JSPs bauen will? Dann brauch ich keine Sourcefolder Und wie gesagt das Archetype ist halt älter, weil sich seit dem nichts groß an dem Aufbau von Webanwendungen geändert hat.

 

[deamon]

Stimmt, der web-app-Archetype passt eigentlich nur zu JSPs. In allen anderen Fällen, wird man Java-Klassen (oder auch Scala-Klassen ...) haben und dann passt er nicht mehr. Und JSP sollte sowieso verboten werden! ;-)

Aber um noch mal auf das eigentliche Thema zurückzukommen: Ich glaube, ich sehe eine Webanwendung modularer als die meisten Entwickler. Ein Servlet mit ein paar Templates ist ja im Prinzip eine kleine, wiederverwendbare Einheit. Wäre es da nicht naheliegend die zusammengehörigen Dateien, auch zusammen zu speichern, so dass man sie Problemlos in eine JAR-Datei packen und anderswo nutzen kann? Das finde ich auch bei Wicket sehr gekonnt. Prinzipiell könnte man ja die grafische Oberfläche auch in Java beschreiben, nur ist es in HTML in der Regel einfacher.

Wenn man die Templates in einer anderen Verzeichnishierarchie hat, geht das nicht mehr. Dann wäre die Webanwendung, also die gesamte WAR-Datei, die kleinste wiederverwendbare Einheit.

 

[Atze]

Prinzipiell könnte man ja die grafische Oberfläche auch in Java beschreiben, nur ist es in HTML in der Regel einfacher.

zum glück gibts ja JavaFxScript

 

[Noctarius]

JavaFxScript gibt es nicht. Es gibt JavaFX was eine Scriptsprache ist.

 

[Atze]

JavaFX Script - Overview

wieso sollte es die bezeichung javafxscript nicht geben?

 

[Noctarius]

Weil die Scriptsprache ansich JavaFx heißt :-D

 

[Atze]

javascript heißt auch net java und ist ne scriptsprache! actionscript, javascript, extendscript, warum nicht javafxscript? außerdem ist javafx die idee, javafxscript ist die sprache, meiner meinung nach

"The JavaFX family of products features a high-performance declarative scripting language, JavaFX Script, for building and delivering the next generation of rich Internet applications for desktop, mobile, TV, and other consumer platforms."

>> "... a high-performance declarative scripting language, JavaFX Script, ..." <<

 

[Noctarius]

Ok in dem Fall überzeugt, aber das Javascript nicht Java heißt ist keine Begründung.
Trotzdem ist JavaFx Script hässlich und erinnert an JavaScript

 

[Atze]

hehe, ich hab noch nichts produktives damit auf die beine gestellt, aber mich eingelesen, und ich finde es sehr interessant. man erspart sich viel listener-gefummel und kann super leicht swing-guis erstellen, nur die zusätzliche benötige api nervt. ansonsten bin ich von fx überzeugt!

 

[Noctarius]

Schnell ist es gewiss, aber diese JSON Notation zur Erstellung von "Klassen" (oder Stages) ist mir zu wider. Vermutlich liegt es aber mehr an meiner grundsätzlichen Abneigung zu untypisierten Sprachen ;-)