 |
AppletTalk.com
Java discussions newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Chris
Guest
|
 Posted: Sat May 05, 2007 7:13 am Post subject: Tomcat Frameworks |
 |
|
Hallo,
meine frage, welche frameworks für den Tomcat nutzt Ihr? Habe mich mal
mit Struts beschäftigt, aber es kann bestimmt nicht schaden noch
weitere zu kennen....
Natürlich soll es ganz einfach zu nutzen sein, aber natürlich alles
können ;-)
gruß
chris |
|
| Back to top |
|
 |
Thomas
Guest
|
| Posted: Sat May 05, 2007 5:18 pm Post subject: Re: Tomcat Frameworks |
|
|
Hallo,
wir nutzen auch Struts. Aber es gibt ja noch Wicket oder das Click
Framework. Aber schau einfach mal hier vorbei.
http://java-source.net/open-source/web-frameworks
Gruß
Thomas
"Chris" <christian.doll.nrw (AT) googlemail (DOT) com> schrieb im Newsbeitrag
news:1178343269.625155.25990 (AT) l77g2000hsb (DOT) googlegroups.com...
meine frage, welche frameworks für den Tomcat nutzt Ihr? Habe mich mal
mit Struts beschäftigt, aber es kann bestimmt nicht schaden noch
weitere zu kennen.... |
|
| Back to top |
|
|
Chris
Guest
|
| Posted: Sat May 05, 2007 7:26 pm Post subject: Re: Tomcat Frameworks |
|
|
oO, gibt ja doch einiges mehr als ich gedacht hatte ;-)
Danke Thomas
Thomas schrieb:
| Quote: | Hallo,
wir nutzen auch Struts. Aber es gibt ja noch Wicket oder das Click
Framework. Aber schau einfach mal hier vorbei.
http://java-source.net/open-source/web-frameworks
Gruß
Thomas
"Chris" <christian.doll.nrw (AT) googlemail (DOT) com> schrieb im Newsbeitrag
news:1178343269.625155.25990 (AT) l77g2000hsb (DOT) googlegroups.com...
meine frage, welche frameworks für den Tomcat nutzt Ihr? Habe mich mal
mit Struts beschäftigt, aber es kann bestimmt nicht schaden noch
weitere zu kennen.... |
|
|
| Back to top |
|
|
Stefan Matthias Aust
Guest
|
| Posted: Sat May 12, 2007 9:41 pm Post subject: Re: Tomcat Frameworks |
|
|
Iridias schrieb:
| Quote: | Wovon ich allerdings begeistert bin ist: SpringFramework
(www.springframework.net)
Das hat so ziemlich alles was man sich wünschen kann. Von IoC/Dependency
Injection bis MVC und AOP.
|
Na ich weiß nicht. Zu viel Configuration und zu wenig Convention, wenn
man mich fragt. Zu simpel könnte man auch sagen.
Was ist Spring MVC? Die Idee, dass es ein DispatcherServlet gibt,
welches über eine zu konfigurierende Abbildung zu konfigurierende
Controller aufrufen kann, die zu konfigurierende Views benutzen können,
um zu konfigurierende Modelle darzustellen. Na toll.
Brauche ich für ein API
interface Controller {
ModelAndView handleRequest(request, response) throws Exception;
}
wirklich ein Rahmenwerk? Zumal sich z.B. PMD daran stört, dass hier eine
nackte Exception geworfen wird.
Okay, okay, ich überspitze das und es gibt noch einige nützliche
Implementierungen von Controller und den anderen Interfaces und das
Grundprinzip ist wirklich so simpel...
Doch wenn's wirklich so simpel ist, warum gleich brauche ich ein
Rahmenwerk?
Wenn mir dieses Entscheidungen abnehmen würde - also Conventions
erzwingen würde - dann könnte ich das verstehen. Aber ich habe immer das
Gefühl, Spring allgemein und Spring MVC im besonderen möchte es allen
Recht machen und ist dabei zwar in der Lage, vielen Leuten zu gefallen,
aber um den Preis der Mittelmäßigkeit. Und nutzen die wirklich das selbe
Rahmenwerk? Oder eher jeder seine Variante? Und spart man dadurch Zeit?
Denn man muss sich ja erstmal auf eine Variante festlegen.
Halte ich mich an die starre Konvention (von Rails abgeguckt aber auch
die waren nicht die ersten, bei Quixote habe ich das schon früher
gesehen) dass ich URLs aus <controller>/<action> mit optionaler <id>
bestehen, kann ich den Dispatcher in wenigen Zeilen selbst bauen.
- url an / splitten
- Controller-Klasse finden (Class.forName())
- In der Klasse Methode finden (Reflections)
- Bei optionaler ID passendes Modell finden (aufwendigster Teil)
- Neues Controller-Exemplar erzeugen
- Methode mit Modell aufrufen
- ggf. Template aufrufen
Definiere ich einmal das Paket der Anwendung - etwa dadurch, dass ich
einen abstrakten Dispatcher einmal in diesem Paket ableite, kann ich
Controller-Klassen aufgrund einer Namenskonvention direkt finden, ohne
das ich etwas konfigurieren muss. Und es gibt IMHO keinen Grund, diese
Konvention nicht zu erzwingen. Die Aktion ist offensichtlich eine
Methode in diesem Controller. Eine weitere erwungene Konvention.
Kümmert sich der Controller nicht selbst um die Darstellung - ich hatte
das in meinem Fall über ein Flag gelöst, besser ist aber möglicherweise
es anhand des Rückgabetyps der Methode festzulegen - oder gibt es keine
passende Aktion, wird ein Template in einem Verzeichnis, dass wie der
Controller heißt und den Namen wie die Aktion hat gesucht. Wenn
vorhanden, wird's ausgegeben. Wenn nicht, ist's ein 404.
Diesen Rahmen kann ich in unter 50 Zeilen (geschätzt) schreiben.
Nun lässt sich das ausbauen: Erwartet z.B. die Methode des Controllers
ein Argument, welches ein Model-Objekt ist und hängt ann der URL eine
<id>, kann ich diese als primary key auffassen und einfach mal das Model
laden. Dazu muss ich natürlich wissen, welcher Controller für welches
Modell zuständig ist, dass muss annotiert werden.
Oder ich erwarte, dass ich Request-Parameter in einem Exemplar der
passenden Klasse setze. Modelle, so erwarte ich, können sich selbst
validieren. Modelle kennen auch ein Errors-Objekt, welches ganz
praktisch für die Darstellung der Fehler ist.
Spring MVC kann etwas ähnliches in dem MultiActionController. Dort muss
das dritte Argument der Methode dann ein Bean sein. Aber man muss den
Controller wieder konfigurieren. Und wenn man einen SimpleFormController
benutzen möchte, wird's ein Krampf: Ich muss den Form-View, den
Success-View, das Kommando und dessen Klasse konfigurieren. Außerdem
muss ich eine onSubmit-Methode überschreiben.
Eine extra-Indirektion bei Views - so wie sie Spring MVC erfordert -
habe ich nie eingesehen. Stattdessen möchte ich einen Mechanismus haben,
der mir aus der Kombination Controller & Action einen URL baut, die ich
dann für redirects nutzen kann - dies scheint mir ein bei Spring
ungelöstes Problem. Da wird nur davon geredet, dass man diese URL als
Konstante bitte in den passenden Controller injecten soll. Nicht gerade DRY.
Ein recht praktisches Prinzip von Rails ist auch, dass der View zur
Aktion eines Controllers normalerweise nochmal in einem Layout gewrappt
wird.
Schließlich könnte man vorsehen, dass wenn eine Anfrage per
XmlHttpRequest ankommt, nicht mit einer HTML-Seite geantwortet wird,
sondern die Modell-Daten direkt json-formatiert zurückgegeben werden.
Um den üblichen Loop bei Formularen zu unterstützen - GET auf eine URL
liefert das Formular, es macht ein POST auf sich selbst; bei Erfolg
geht's mit redirect weiter, ansonsten kommt das Formular mit den Fehlern
- bin ich mir unsicher, wie viel Rahmenwerk man denn nun braucht.
Hier ein ganz einfacher Fall a la sma-Microrahmenwerk:
class BookController extends Controller {
Context edit(Book book) {
if (isPost())
if (book.isValid())
return redirect(url("list"));
return context(book);
}
}
Der Controller kennt Request und Response und hält sie in
Exemplarvariablen. Er weiß daher, ob's ein POST war. Ein Book ist ein
Model und dies wiederum kann sich selbst validieren. redirect() und
url() sind zwei weitere Methoden von Controller. Mit context() kann ich
im Prinzip eine HashMap erzeugen mit Werten, die als Request-Attribute
gesetzt werden, damit das Template-System auf diese Zugreifen kann.
Ich hatte damit experimentiert, einfach alles, was ich im View haben
will - ganz im Rails-Stil - in Exemplarvariablen zu packen, die dann mit
einer Annotation @Expose markiert werden, doch das war irgendwie nicht
griffig.
Wenn man den isPost-Test nicht haben will, könnte man das Rahmenwerk
erweitern, dass es für POST erst noch nach einer zweiten Methoden sucht:
Context edit_post(Book book) {
return book.isValid() ? redirect(url("list")) : context(book);
}
Context edit(Book book) {
return context(book);
}
und zufällig wäre die Implementierung der zweiten Methode der
Standardfall und man könnte diese Methode auch weglassen. Mit gefällt
die explizite erste Variante aber zur Zeit besser.
Bis auf wenige Ausnahmen, die ich erst mal nachschauen müsste - etwa
file upload mittels commons-fileupload - bilde ich mir aber ein, es geht
schneller, sich selbst den notwendigen Code zu schreiben als sich in
etwas wie Spring einzuarbeiten.
Spring bietet natürlich noch mehr als das Web-Rahmenwerk. Aber für
meinen Anwendungfalls war es absolut ausreichend etwas wie
class MyController {
@Resource protected MyService service;
...
}
zu benutzen und beim Erzeugen des Controllers werden alle als @Resource
markierten Variablen (oder setter, das wäre noch einfacher, hatte ich
aber nicht so implementiert) automatisch aus dem ServletContext befüllt.
In der DispatcherServlet-Unterklasse war es einfach genug, hier manuell
den Context zu befüllen. Das war gut genug für mich, um leichtgewichtig
DI zu implementieren.
Ich musste nur für die richtige Reihenfolge sorgen und wechselseitige
Abhängigkeiten kann ich damit nicht auflösen. Brauchte ich aber nicht.
Mein DI-Microrahmenwerk braucht vielleicht 20 Zeilen Code. Im Prinzip
ist es:
void register(String id, Object o) {
setAttribute(id, populate(o));
}
private void populate(Object o) {
for (Field f : o.getClass().getFields())
if (f.getAnnotation(Resource.class)) {
f.setAccessible(true);
f.set(o, getAttribute(f.getName()));
}
}
Was ich damit sagen wollte? Keep it Simple, Stupid.
--
Stefan Matthias Aust |
|
| Back to top |
|
|
Steffen Ramlow
Guest
|
| Posted: Sat May 12, 2007 10:54 pm Post subject: Re: Tomcat Frameworks |
|
|
Stefan Matthias Aust wrote:
| Quote: | (www.springframework.net)
Na ich weiß nicht. Zu viel Configuration und zu wenig Convention, wenn
man mich fragt. Zu simpel könnte man auch sagen.
|
Hm. Bist du schon bei 2.0 angekommen? Da gibt es haufenweise Konvention, den
p-Namespace und die Spring-IDE nimmt massiv Tipparbeit ab.
Seit Kurzem auch Spring-Config, ganz ohne XML.
Und CoC ist bei MVC auch nett.
| Quote: | Was ist Spring MVC?
Doch wenn's wirklich so simpel ist, warum gleich brauche ich ein
Rahmenwerk?
|
Weil da haufenweise Zeugs per PnP drinsteckt. Validation, Form state,
Exception Handling, Auth, Caching, ...
| Quote: | Und es gibt IMHO keinen Grund, diese Konvention nicht zu erzwingen.
|
Doch. Wenn man "Legacy-Apps" langsam in Spring-MVC überführt. Da ist es sehr
hilfreich, wenn man nicht zig Pfade in seinen JSPs anpassen muss.
| Quote: | Diesen Rahmen kann ich in unter 50 Zeilen (geschätzt) schreiben.
|
Siehe oben, Spring MVC ist viel mehr, als das Mapping von Requests auf
Controller auf Views.
| Quote: | Eine extra-Indirektion bei Views - so wie sie Spring MVC erfordert -
habe ich nie eingesehen. Stattdessen möchte ich einen Mechanismus
haben, der mir aus der Kombination Controller & Action einen URL
baut, die ich dann für redirects nutzen kann - dies scheint mir ein
bei Spring
ungelöstes Problem. Da wird nur davon geredet, dass man diese URL als
Konstante bitte in den passenden Controller injecten soll. Nicht
gerade DRY.
|
CoC MVC löst das Problem bereits.
Und wenns das nicht ist, es gibt ja Viewresolver.
| Quote: | Ein recht praktisches Prinzip von Rails ist auch, dass der View zur
Aktion eines Controllers normalerweise nochmal in einem Layout
gewrappt wird.
Schließlich könnte man vorsehen, dass wenn eine Anfrage per
XmlHttpRequest ankommt, nicht mit einer HTML-Seite geantwortet wird,
sondern die Modell-Daten direkt json-formatiert zurückgegeben werden.
|
Dafür gibt es ja die DWR-Integration.
| Quote: | Hier ein ganz einfacher Fall a la sma-Microrahmenwerk:
|
Na du nun wieder. Beschwerst dich über zu viele Frameworks und baust ständig
(theoretisch) selbst welche.
| Quote: | Spring bietet natürlich noch mehr als das Web-Rahmenwerk.
|
Und genau da entsteht der Mehrwert. Spring-MVC allein, na ja, das würde wohl
niemand nutzen.
| Quote: | Was ich damit sagen wollte? Keep it Simple, Stupid.
|
Nur nicht zu simple. Was Spring allein mit Acegi mitbringt, dass wirst du
mit 20 Zeilen nicht hinbeommen 
Und ich finde Spring nicht kompliziert.
--
Turbine from hell
http://www.youtube.com/watch?v=HKOivVnoC3Y |
|
| Back to top |
|
|
Steffen Ramlow
Guest
|
| Posted: Sun May 13, 2007 9:31 pm Post subject: Re: Tomcat Frameworks |
|
|
Stefan Matthias Aust wrote:
| Quote: | Tipparbeit ist egal - das Lesen ist das Problem, nicht das Schreiben.
|
p-Namespace & Co reduziert die Menge des XML beträchtlich, was, zumindest
für mich, die Lesbarkeit deutlich erhöht.
| Quote: | Und nein, ich bin auf 1.2.x, wollte aber auf 2.0 umstellen und würde
gerne wissen, wo da haufenweise Konventionen sind. Meinst du Abschnitt
13.11?
|
13.11 ist CoC für S-MVC.
Spring an sich hat natürlich noch andere diverse Konvention, z.B. finde ich
das Autowiring sehr schön.
| Quote: | Da muss ich ja sogar erstmal die Konvention konfigurieren was ich das
letzte Mal ja ansprach: Zu flexibel für meinen Geschmack.
|
Wie gesagt, ich finde die freie Wahl gut. Nicht immer passt CoC.
| Quote: | Gegen das XML-Format habe ich nichts. Und ich möchte, dass man's dort
einstellen kann, weil das Änderungen an der Funktion unseres Systems
erlaubt, ohne das jemand den Quelltext haben, verstehen und
kompilieren muss.
|
Ich finde, dass der der ändert, also wahrscheinlich der Admin des Kunden,
auf keinen Fall in der XML-Konfig rumrühren sollte, da kann ich ihm gleich
den Quelltext geben und sagen: Hier ändere dir was du brauchst ;)
| Quote: | Nun, ich habe es natürlich durch den Filter der Funktionen
betrachtet, die ich nur brauche. Validierungen fand ich einfacher im
Code explizit durchzuführen.
|
Mit der Zeit wirst du diverse Validatoren haben, die du nur noch
zusammenstöpselst und von Außen reinkonfigurierst. In der direkten
Businesslogik haben Validierung und andere CCC m.E. nix zu suchen.
| Quote: | Unter Form-State kann ich mir gerade
nix vorstellen.
|
Dass das Formular nach dem Submit den Inhalt "behält", z.B. bei
Validierungsfehler.
| Quote: | Okay, das Argument kann ich einsehen, ist aber für mich, der
wahrscheinlich eher ein System sucht, mit dem er schnell "from
scratch" eine fertige Lösung bauen kann, egal.
|
Dann ist sicher Rails und Co besser.
Das ist wie früher VB auf der Client-Seite. Web-RAD sozusagen :)
| Quote: | Mehr brauche ich aber nicht und (viel) mehr brauchen auch die tausende
von Leuten, die Rails benutzen, auch nicht. Somit ist es mir fast
egal, ob Spring MVC nun wirklich viel mehr ist oder nicht. Im
Gegenteil, es stört sogar, wenn das mehr kann als nötig, weil dieser
Ballast ablenkt.
|
Das Problem ist nur, das Anwendungen wachsen. Und wenn dein Rahmen nicht
mitwachsen kann, dann stehste da :)
| Quote: | ungelöstes Problem. Da wird nur davon geredet, dass man diese URL
als Konstante bitte in den passenden Controller injecten soll. Nicht
gerade DRY.
CoC MVC löst das Problem bereits.
Wie? Kannst du da mal ein Beispiel geben? Ich habe nix gefunden.
Abschnitt 13.5.3.2 sagt, man möge doch bitte den Namen injecten.
@Tip(name="org.springframework.web.servlet.view.DefaultRequestToViewNameTranslator") |
:)
| Quote: | Wenn ich aber das Beispiel machen will, dass sich der Controller
selbst ein redirect schickt, um von dem POST wieder auf ein GET zu
kommen, dann muss ich an zwei Stellen meine URL hinterlegen. Einmal im
HandlerMapping, damit der Dispatcher weiß, welchen Controller er für
die URL nehmen soll und einem im Controller, der auch nochmal die URL
braucht.
|
getSuccessView() sollte helfen.
| Quote: | Und das Argument, dass es für Spring und Co ja Bücher und alles
mögliche gibt trifft IMHO nicht zu, wenn ich in 50 Zeilen den Code
lesen und verstehen kann geht das immer noch schneller, als auch nur
im
Spring-Buch das richtige Kapitel zu finden
|
Na ja, das mit den 50 Zeilen dürfte deutlich untertrieben sein, es sei denn,
deine Zeilen sind um die 1000 Zeichen lang 
Und: Ich les keine Bücher, wo es keine Toten gibt >:)
| Quote: | Eben. Sage ich doch. Aber darum gings doch ursprünglich bei der
Aussage, Spring MVC wäre ein tolles "Tomcat Framework".
|
Na ja, es endet ja nie in der View. Irgendwoher müssen die Daten ja auch
kommen und irgendwohin gehen.
Und da ist Spring ein ziemlich runder Stack.
| Quote: | Auf Acegisecurity.org lese ich etwas von 100 Seiten Reference-Guide.
Das schreckt mich schon wieder total ab.
|
Ist das so? Hm. Ja ok, das Teil ist brutal mächtig.
Aber meist reicht es, ein Tutorial anzusehen. Die sind kurz.
| Quote: | In meinem Fall möchte ich sicherstellen, dass jede URL einen
"u"-Parameter mit dem user enthält und falls dies nicht der Fall ist,
einen Login-Dialog dazwischen schieben. Dafür lese ich keine 100
Seiten Reference-Guide.
|
Also ich hab die nicht gelesen, weiß aber, dass ein AuthenticationEntryPoint
die Lösung sein könnte.
| Quote: | jedes Konzept für sich ist nicht wirklich kompliziert.
|
Na Regex werd ich in diesem Leben nicht mehr wirklich verstehen :)
| Quote: | Aber wenn du eine Spring-Anwendung verstehen willst, kann's
unübersichtlich werden
und das ist das eine Form von Komplizität, die ich nicht haben möchte.
|
Hey, du hast meinen Code noch nicht gesehen, spart jeden Obfuscator >:)
--
Turbine from hell
http://www.youtube.com/watch?v=HKOivVnoC3Y |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
