JSP vs PHP

[maki]

Eigentlich wollte ich hören, daß es eine perfekte Schablone ist, den MVC Controller in JSP Front Strategy zu auszuprogrammieren, wie in den Patternkatalogen zu J2EE u.a. vorgeschlagen.

Ähh.. das wirst du von mir nicht hören, weil es halt nicht stimmt.
Den Controller in die View zu programmieren ist das Gegenteil von SOC und das Gegenteil MVC.
Wie du darauf kommst dass das im JEE Pattern Katalog vorgeschlagen wird, würde ich trotzdem gerne wissen, genau das wird mit dem JEE Patternkatalog verhindert bzw. nicht empfohlen(vom sog. "Model 1" wurde immer schon abgeraten ).

Das ist eine "saubere" Technik, die einem das Servlet und das herumgefrickel in der web.xml erspart. Diese hat sich eigentlich nur in Java nicht durchgesetzt, weil Debugger und IDEs damit zu der entscheidenden Zeit noch nicht zurechtgekommen sind.

Nein, ist nicht sauber und hat auch nix mit Debuggingunterstützung zu tun.
MVC war das Ziel, sauber baer eben aufwändiger.

 

[bronks]

... MVC. Wie du darauf kommst dass das im JEE Pattern Katalog vorgeschlagen wird, würde ich trotzdem gerne wissen, genau das wird mit dem JEE Patternkatalog verhindert bzw. nicht empfohlen(vom sog. "Model 1" wurde immer schon abgeraten ).

Doch, doch. Das ist absolut konform zu MVC Model 2 und steht in den Sun Blue Prints immer noch so drin, denn es ist egal, ob absolut der selbe ControllerCode im Servlet oder oder im Kopf der JSP steht, denn die Anfrage geht so oder so direkt an den Controller.

Nein, ist nicht sauber und hat auch nix mit Debuggingunterstützung zu tun ... ...

Doch klar. Notgedrungen hat man den Controller im Servlet belassen, da kaum ein Debuggingwerkzeug sich für die Breakpoints in der JSP interessiert hat und wenn, dann hat das Programm an total blödsinnigen Stellen angehalten. War insgesammt ein toller Workaround, um die Sitiuation zu retten, aber eigentlich hätte man alles lieber in der JSP gehabt und Servlets nur für LowLevelSachen propagiert.

 

[marasek]

Bevor das zum üblichen "I am smarter than thou" degeneriert, eine Erläuterung: wenn ich mit PHP programmiere, habe ich eine index.php5. Darin wird der Klassenlader definiert, Konfiguration geladen & sonstiger Krimskrams, und danach gibt es den Aufruf des Frontcontrollers. Irgendwo gammeln dann noch ein paar HTML-Templates rum.

Übrigens ist MVC nicht der Weisheit letzter Schluss. Mal angenommen, man gibt eine grosse Tabelle aus. echo "<td>".$cell."</td>"; ist nicht sonderlich elegant, hat aber den Vorteil, dass die Liste bereits angezeigt wird, während die Liste geladen wird.

By the book ist das anders - da kommt eine längere Zeit die Sanduhr und dann die Seite, bis die Daten von der Datenbank ins Model, vom Model in das TableWidget, vom Widget ins Template und vom Template an den Browser gegangen sind...

 

[Spin]

Einfach mal WIKI schauen

JSP ist einfach zu erlernen , wenn du die Basics von Java beherschst. Es sollte für einen PHP entwickler der schon 6 Jahre dabei ist kein Problem sein.

Naja ich kenn einige die haben noch nie was von OOP gehört.......also nur prozedural programmiert.

Das kann dann doch zu schwierigkeiten kommen. Aber versucht euch

Tipp: Galileo open sourcs OOP

schau euch das an, grüße

 

[maki]

Doch, doch. Das ist absolut konform zu MVC Model 2 und steht in den Sun Blue Prints immer noch so drin, denn es ist egal, ob absolut der selbe ControllerCode im Servlet oder oder im Kopf der JSP steht, denn die Anfrage geht so oder so direkt an den Controller.

Natürlich macht es einen Riesenunterschied ob ich den Java Code in die JSP Schreibe oder einen extra Servlet als Controller verwende.
Aber du hast sicherlich einen Link zu den Blueprints der deine Behauptung belegt, nicht wahr?

Doch klar. Notgedrungen hat man den Controller im Servlet belassen, da kaum ein Debuggingwerkzeug sich für die Breakpoints in der JSP interessiert hat und wenn, dann hat das Programm an total blödsinnigen Stellen angehalten. War insgesammt ein toller Workaround, um die Sitiuation zu retten, aber eigentlich hätte man alles lieber in der JSP gehabt und Servlets nur für LowLevelSachen propagiert.

Ich denke du solltest dir wirklich mal die Grundlagen der Webentwicklung in Java ansehen...

 

[bronks]

... Aber du hast sicherlich einen Link zu den Blueprints der deine Behauptung belegt, nicht wahr? ...

Klar doch: Core J2EE Patterns - Front Controller

Der Absatz über Beispielcode 7.15 beschreibt das was ich oben geschrieben habe. Testing und Debugging von JavaCode in JSP war ein fast unmöglicher Grusel zu der Zeit wo das Dokument geschrieben wurde.

 

[maki]

Das hier

Ich denke du solltest dir wirklich mal die Grundlagen der Webentwicklung in Java ansehen...

nehme ich zurück.

Der Absatz über Beispielcode 7.15 beschreibt das was ich oben geschrieben habe. Testing und Debugging von JavaCode in JSP war ein fast unmöglicher Grusel zu der Zeit wo das Dokument geschrieben wurde.

Da wird auch klar davon abgeraten (bzw. der Vorzug wird dem Controller Servlet gegeben) den Controller in die JSP mitreinzuprogrammieren, aber nicht wegen dem Debugging:

JSP Front Strategy

This strategy suggests implementing the controller as a JSP page. Though semantically equivalent, the Servlet Front Strategy is preferred to the JSP Front Strategy. Since the controller handles processing that is not specifically related to display formatting, it is a mismatch to implement this component as a JSP page.

Implementing the controller as a JSP page is clearly not preferred for another reason: It requires a software developer to work with a page of markup in order to modify request handling logic. Thus, a software developer will typically find the JSP Front Strategy more cumbersome when completing the cycle of coding, compilation, testing, and debugging. Example 7.15 is an example of the JSP Front Strategy.

Jedenfalls ist da nicht von der "perfekten Schablone" die Rede