Tiles VS Frames

[DreamArtist]

Hallo Leute,
in meiner Firma starten wir ein größeres J2EE-Projekt.
Und seltsamer Weise wurde bei einer Besprechung gegen Tiles und für Frames gestimmt. :?:

Der Grund der Entscheidung war folgender:

1. Frames sorgen für weniger Datentransfer, das Header und Footer nur einmal geladen wird.
2. Durch Frames wird immer das Seitenlayout beibehalten (Wenn der Content-Bereich größer wird kann man diesen separat scrollen ohne den Header aus den Augen zu verlieren.
3. Mann kann einzelne Applikation separat der Navigation als War-Archive entwickeln und so die Unabhängigkeit dieser gewähren.

Was für Argumente kann man nun noch einbringen um doch noch eine Überzeugung für Tiles zu bewirken? :###

Könnt Ihr mir hier einige nennen?

Vielen Dank

 

[KSG9|sebastian]

Frames ? Das ist ein Scherz, oder ?

 

[Bleiglanz]

Da waren ja wohl echte Experten am Werk

1. Frames sind bescheurt beim Reloaden (vor allem wenn Sessions verwendet werden, man muss dann die Session_ID durch alle Frames durchschleifen)

2. Frames irritieren die User beim aktualisieren

3. Frames irritieren die User beim ausdrucken

4. Frames haben keinerlei Vorteile bei der Navigation, und weil sie vom Rest der Anwendung entkoppelt sind, kann man ohne Probleme 404s produzieren

5. natürlich hat man ein "Seitenlayout", aber das ist mit Tiles hundertmal besser gelöst

6. schau mal unter useit.com nach frames

7. Frames sind auch beschauert, wenn Authentifizierung zum Einsatz kommt

8. Frames machen probleme beim Bookmarken

9. Frames machen probleme beim Verlinken

10. Frames machen probleme für Suchmaschinen

noch mehr?

11. Der Einsatz von Frames zeigt, dass Stümper am Werk sind

und das mit dem "Naviagion als war" und dann als "Frame" einbinden, dass muss ja wohl ein völlig krankes verwirrtes Gehirn ausgedacht haben...

 

[KSG9|sebastian]

und das mit dem "Naviagion als war" und dann als "Frame" einbinden, dass muss ja wohl ein völlig krankes verwirrtes Gehirn ausgedacht haben...

Ja..das klingt nicht wirklich klug

 

[DreamArtist]

Also mal danke für die Antwort, aber ganz ist das nicht gelöst für mich.

Zu Bleiglanz.

Frames sind bescheurt beim Reloaden (vor allem wenn Sessions verwendet werden, man muss dann die Session_ID durch alle Frames durchschleifen)

Das mit der Session_ID durchschleifen stimmt. Aber welche Probleme beim Reloaden?

Frames irritieren die User beim ausdrucken

Der Ausdruck wird vom Programm gesteuert, Es öffnet sich eine neue Seite in der die Inhalte des Programmes Druckfreundlich dargestellt werden.

Frames haben keinerlei Vorteile bei der Navigation, und weil sie vom Rest der Anwendung entkoppelt sind, kann man ohne Probleme 404s produzieren

Wenn ich in der Struts.config einen falschen Link angebe habe ich ja ebenfalls eine 404.

natürlich hat man ein "Seitenlayout", aber das ist mit Tiles hundertmal besser gelöst

Und genau dieses besser zu argumentieren fehlt mir!

Frames sind auch beschauert, wenn Authentifizierung zum Einsatz kommt

Stimmt, es ist auch deswegen geplant das jede Frame kontrolliert ob der Benutzer auch nur das sieht was er sehen darf.

Frames machen probleme beim Bookmarken

Bookmarks sollen auch nicht gesetzt werden, alle erlaubte Applikationen werden erst nach Anmeldung aus der Datenbank gelesen. Ohne Anmeldung keine Applikation.

Frames machen probleme beim Verlinken

Weswegen? Ich würd als Target stets Content angeben.

Frames machen probleme für Suchmaschinen

Intranetapplikation

Der Einsatz von Frames zeigt, dass Stümper am Werk sind

würde ich so nicht behaupten, vor allem weil es keine fachliche Argumentation ist.

Was also spricht so für Tiles dass ich diese den Frames vorziehen soll


Zu KSG9|plak

Hier fehlt mir die fachliche Argumentation, das liest sich eher nach deiner persönlichen Meinung.

 

[Bleiglanz]

Frag doch mal einen Webentwickler (egal ob Java PHP oder sonst was), welche Erfahrungen er mit einer geframten dynamischen Site gemacht hat...

Hauptargument: Wenn du drei Frames im Browserfenster beim Client anzeigst, dann ist das ungefähr so wie drei gleichzeitig offene Browserfenster bzw. drei gleichzeitige Sitzungen

Wenn du mit Authentifizierung und Sessions arbeitest, dann kannst du am Server ständig eine "Synchronisation" dieser Sessions durchführen

Warts einfach ab, irgendwann kommt der Chef und sagt: "aber wenn sich das im rechten frame ändert, dann soll es sich im linken aber auch ändern..."

=> das wird dann mit völlig absurden javascripts erledigt, die 2 frames gleichzeitig neu laden und ähnlich schrottigen designs

oder wenn er sich im rechten frame abmeldet, was ist dann mit der navigationsleiste im linken frame??

usw. usf.: Wenn es einen serverseitigen "Zustand" gibt, dann führen Frames zu einem ganzen Haufen von Problemen, die man ohne Frames nicht hätte...

Das mit der Session_ID durchschleifen stimmt. Aber welche Probleme beim Reloaden?

Du musst auf der Serverseite immer unterscheiden, ob der aktuelle Frame oder das ganze Frameset gereloadet wird, zumindest dann, wenn Sessions zum einsatz kommen?!

Der Ausdruck wird vom Programm gesteuert, Es öffnet sich eine neue Seite in der die Inhalte des Programmes Druckfreundlich dargestellt werden.

Toll, trotzdem bleiben die Browser-Buttons aktiv, de facto wollt ihr den Benutzern also die Browser Buttons wegnehmen

Wenn ich in der Struts.config einen falschen Link angebe habe ich ja ebenfalls eine 404.

das schon, aber wegen der losen kopplung ist das ganze bei frames noch ein bisschen schwieriger

Stimmt, es ist auch deswegen geplant das jede Frame kontrolliert ob der Benutzer auch nur das sieht was er sehen darf.

Was für eine sinnlose Verschwendung von Entwickler-Ressourcen

Bookmarks sollen auch nicht gesetzt werden, alle erlaubte Applikationen werden erst nach Anmeldung aus der Datenbank gelesen. Ohne Anmeldung keine Applikation.

AHA, nehmen wir den Benutzern also auch noch die Bookmarkfunktion weg. Also keine Bookmarks, Drucken fraglich und die wichtigste Funkion ("Zurück") funktioniert auch nicht wie gewohnt...

Weswegen? Ich würd als Target stets Content angeben.

hä? Was solln das sein??

 

[Bleiglanz]

anders gesagt:

für Tiles spricht, dass das Modell

HTTP Request -> Server-seitige verarbeitung -> Antwort ist EINE Html-Datei

für die Entwickler wesentlich leichter zu verstehen und zu programmieren ist ("State") und dass bei den Endanwendern der Zurück-Button wie gewohnt funktioniert

 

[DreamArtist]

Hallo Bleiglanz, zuerst mal Danke für Deine Zeit, ich selbst bin auch lieber für Tiles, aber warum kann ich nicht ganz erklären. Deswegen die Fragen und ein paar Fragen noch an Dich:

für die Entwickler wesentlich leichter zu verstehen und zu programmieren ist ("State") und dass bei den Endanwendern der Zurück-Button wie gewohnt funktioniert

Stimmt, aber bei uns sind Programmierer und Webentwickler ein und die selbe Person, jedes Projekt hat ein oder zwei Java-Entwickler die auch für die HTML-Seiten zuständig sind. Und einen Java-Entwickler sollte man das zumuten können.

Hauptargument: Wenn du drei Frames im Browserfenster beim Client anzeigst, dann ist das ungefähr so wie drei gleichzeitig offene Browserfenster bzw. drei gleichzeitige Sitzungen

Stimmt, das bedeutet in unseren Betrieb bei ca. 1500 Benutzer * 5 Frames = 7500 Zugriffe max. Das sollte der Server (JBOSS) jedenfalls verkraften, zusätzlich haben wir die Garantie das Cookies aktiviert sind.

Wenn du mit Authentifizierung und Sessions arbeitest, dann kannst du am Server ständig eine "Synchronisation" dieser Sessions durchführen

Stimmt, aber das ist ein Workaround der sich durch alle Projekte zieht und wenn einmal entworfen für keine Probleme mehr sorgen sollte.

Warts einfach ab, irgendwann kommt der Chef und sagt: "aber wenn sich das im rechten frame ändert, dann soll es sich im linken aber auch ändern..."

Stimmt und das ist auch meine Hauptgegenargument gewesen, wurde aber mit dem Gegenargument zerschmettert da JS ohnehin bei der Validierung der Formulare verwendet wird, also kann man es für Framesteuerung auch verwenden, ausserdem handelt es dabei ja nicht um schwierige Browserabhänge Scripts.

Toll, trotzdem bleiben die Browser-Buttons aktiv, de facto wollt ihr den Benutzern also die Browser Buttons wegnehmen

Ja ist zwar nicht nett aber das hätten wir ohnehin getan, da bei der Benutzerseite immer das Menü, der Header und das Menü angezeigt wird. Somit haben alle Programme einen Druck-Button der eine neue Seite öffnet in dem der Contet-Bereich (Hauptteil, Programm) mit einen des Programm entsprechenden Headers angezeigt wird.

Stimmt, es ist auch deswegen geplant das jede Frame kontrolliert ob der Benutzer auch nur das sieht was er sehen darf.

Was für eine sinnlose Verschwendung von Entwickler-Ressourcen

Naja, diese Überprüfung müssen wir ohnehin durchführen, es wäre ja so auch möglich einfach apllName.do anzugeben ohne das der Benutzer berechtigt wäre.

Zitat:

Weswegen? Ich würd als Target stets Content angeben.

hä? Was solln das sein??

Für den Link in dem Menübereich würde ich angeben das er die Seite ins frame laden soll das für den Content-Bereich zuständig ist, und mittels JS (gefällt mir auch nicht) die anderen reloaden wenn nötig.

Es geht hier einfach um die Gegenüberstellung der Vor und Nachteile der Technologien.

Und mir sind kaum überwältigende Vorteile von Tiles eingefallen.
Besonder solche die mit Frames nicht realisierbar sind.

 

[Bleiglanz]

Und mir sind kaum überwältigende Vorteile von Tiles eingefallen.
Besonder solche die mit Frames nicht realisierbar sind.

Keine Angst, die Vorteile werden euch schnell klar werden wenn ihr erst mal zwei oder drei Frames per Javascript "aktualisieren" wollt und das vom Server aus anstossen müsst....

Stimmt, das bedeutet in unseren Betrieb bei ca. 1500 Benutzer * 5 Frames = 7500 Zugriffe max. Das sollte der Server (JBOSS) jedenfalls verkraften, zusätzlich haben wir die Garantie das Cookies aktiviert sind.

Es geht doch gar nicht um die Serverlast, in der Beziehung sind Frames sogar besser (weil ja nicht immer neu geladen usw.), aber die paar Kilobyte machen das Kraut i.A. nicht fett

es geht eher darum

Frame1: seit 5 Minuten unverändert

Frame2: seit 3 Minuten unverändert

Frame3. wird gerade neu geladen

hoppla, User klickt jetzt auch noch in Frame1 auf Reload

ahh mist jetzt sollte sich auch frame2 ändern

wo soll eigentlich ein login-button hin?

usw...

Durch Frames wird die ganze serverseitige Verarbeitung des Client-Zustands völlig zerspittert, aber wenn du das nicht als Vorteil sehen willst ist auch recht!

IMHO ist es einfach so, dass ein Frame entweder total statisch ist (dann kann man ihn ja ohne Probleme in ein Tile legen oder gleich ins HTML-Template packen) oder dass er einen Teil der "Dynamik" der Anwendung mitmachen soll. Und in diesem Fall schreibt man einen Haufen mistigen Javascript Schrott.

Ausserdem gehts ja auch um die Hausfrauen draussen an den Browsern, die alle gewisse vorstellungen davon haben, wie ein zurückbutton funktioniert, auch gibts hampelmänner wie mich, die ohne nachzudenken fast alle Links im Firefox mit der mitlleren Maustaste anklicken (und so einen neuen Tab aufmachen....)

http://www.useit.com/alertbox/9612.html

 

[DreamArtist]

Vielen Dank nochmal für die Infos Bleiglanz.

Konnte unsere Leitung aber leider nicht davon überzeugen, sind heute mit dem ersten Testprogramm gestartet.
Kämpfen aber schon mit den ersten Problemen (Session durchschleifen).

Der vollständigkeitshalber möchte ich kurz den Projektplan angeben:

Wir haben ein Frameset das sich aus vier Frames zusammensetzt (Header, Submenu, Content, Footer).
Die Navigation soll dabei ein eigenes war sein.
Alle Applikationen sollen als unabhängige wars angelegt werden, diese sollen über das Submenu-Frame in das ContentFrame geladen werden.

Und das versuchen wir nun mit Frames an der Stelle von Tiles.
Mal sehen wie viele Hilfeposts ich brauche :wink:

Das erste habe ich schon gepostet.

Danke Dir aber nochmal für die Müh.

 

[Bleiglanz]

Die Navigation soll dabei ein eigenes war sein.
Alle Applikationen sollen als unabhängige wars angelegt werden

Das ist doch kompletter ***t, wie wollt ihr da Sitzungsinformationen austauschen (eine Http-Session greift normalerweise nicht über eine Webapplikation hinaus)??

solche "cross-Context" Programmierung ist einfach blöd, dazu kommen bei euch wohl vier verschiedene web.xml...

viel Spass damit

 

[DreamArtist]

Nachdem wir nun doch einige Probleme mit Frames hatten und die Vorzüge von Frames mittlerweile auch ohne Frames abbilden können, wurde die Entscheidung zu Frames nun revidiert (Danke Bleiglanz).

Aber wo Licht da auch Schatten,

es ergibt das Problem externe Seiten für die Layout-Tiles zu inkludieren.

Grund: Mehrere wars sollen das gleiche Layout verwenden.

Habe nun mittels Tiles ein Layout, die einzelnen Tiles möchte ich aber Projektextern auslagern so, dass diese allen Projekten zur Verfügung stehen um bei Änderungen nicht in jedem Projekt geändert werden müssen.

Struts schafft es jedoch jede Art von Include auf das Projekt zu beziehen.

Wie kann man diese Hartnäckigkeit umgehen?

 

[Bleiglanz]

ich würd die Datei 4 in alle wars reinkopieren

als Teil des build-prozesses mit ant

is die einfachste lösung oder als String in den JNDI Baum legen, in datei extrahieren usw. usf.; aber dann ist das Deployment der wars wieder aufwändiger

 

[DreamArtist]

Hallo,

Die Lösung:

ich würd die Datei 4 in alle wars reinkopieren

wurde zwar kurz durchdacht, da aber mehrere Entwickler das gleiche Layout verwenden sollen und sich dies auch ändern kann, wäre es bei über 40 wars ein Horror diese bei einer Layoutänderung alle neu zu öffnen und zu deployen.

Die Lösung:

als String in den JNDI Baum legen, in datei extrahieren usw. usf.; aber dann ist das Deployment der wars wieder aufwändiger

wäre möglich, da aber der Inhalt Variable sein kann würde es hier ebenfalls Schwierigkeiten geben.

Danke für die Vorschläge, aber ich glaube ich hab da noch ne Lösung gefunden:

Ein eigenes jar mit Klassen die statische Methoden haben (z.B.:

 public static String getHeaderTile(String logoPfad)

, diese erhalten eine Reihe von Argumenten und liefern einen String zurück.
Dieses jar dann in das lib-Verzeichnis vom JBOSS.
Jetzt greifen alle Wars auf denselben String zu, die Widerverwertbarkeit ist vorhanden und die Wartbarkeit ist ebenfalls ideal.

Was sagst? Finde die Lösung toll!

 

[Bleiglanz]

ist ok

aber immer ein bissl strange, weil man da eine abhängigkeit von der server-landschaft mit einbaut

(man muss halt beim deployment immer dran denken, aber wenns eh nur auf einem server laufen soll gehts klar)

wäre es bei über 40 wars ein Horror diese bei einer Layoutänderung alle neu zu öffnen und zu deployen.

deshalb würde ich das ja mit einem ant-task automatisieren, würde auf Knopfdruck ablaufen (und dauert natürlich etwas)

BTW: was soll das für ein projekt sein mit 40 wars????

 

[DreamArtist]

Bin mir nicht sicher ob ich dieses Post mit der Firmenphilosophie vereinbahren lässt.
Danke Dir aber nochmal für die Hilfe .
Mal sehen wie lange es dauern wird bis meine AntwortPost meine FragenPost übersteigen :wink:

 

[Bleiglanz]

wenns gut dokumentiert ist (und sich keine anderen Anwendungen dran stören) kann man pragmatisch durchaus alles ins /lib schmeissen...

ist halt dann nicht mehr so richtig portabel, aber das ist in der praxis eh selten

 

[DreamArtist]

Schmeißen auch nur Projektübergreifendes, wie Layout oder Service-Methoden rein.
Ansonst sollte schon alles im eigenen war sein.