JSF-Hyperlinks unter dem Aspekt der Suchmaschinenindexierung

[MichiM]

Grüß Euch,

wenn ich es denn richtig sehe, läuft die Navigation konsequent mit JSF umgesetzten Seiten über den Controller, womit Suchmaschinen an die Inhalte nicht ohne Weiteres rankommen...

Wie geht Ihr mit der Tatsache um?

Baut Ihr Eure Hauptmenüs von JSF-Portalen dennoch aus JSF-Hyperlinks auf oder nur dann, wenn die verlinkten Unterseiten keinen Inhalt tragen, der der Indexierung würdig ist oder verzichtet Ihr im Hauptmenü darauf und verwendet JSF-Hyperlinks nur für luxuriöse Navigation (Link "zurück" etc.)?

Gruß Michi

 

[Terminator]

> wenn ich es denn richtig sehe, läuft die Navigation konsequent mit JSF umgesetzten Seiten über den Controller

POST-Navigation ist totaler Schwachsinn.
Keine Ahnung warum das JSF Büchern/Tutorials so propagiert.



> JSF-Portalen dennoch aus JSF-Hyperlinks

muss man ja sonst würde session id verloren gehen, wenn cookie deaktiviert ist.
halt mit output link, aber nicht command links.
command links eben nur für "echte" POST actions, also wenn eine Action am Server auch eine Änderung durchführt.

 

[maki]

POST-Navigation ist totaler Schwachsinn.
Keine Ahnung warum das JSF Büchern/Tutorials so propagiert.

Weil mit der Navigation meist mehr gemacht wird als nur eine einfache Seite darzustelllen, Stichwort Phaselistener, in denen man zB. "gelockte" Objekte wieder freigibt etc. pp.

POST Navigation ist der Standard, GET reicht gerade mal um die Login Seite zu bekommen.

 

[Terminator]

> Weil mit der Navigation meist mehr gemacht wird als nur eine einfache Seite darzustelllen, Stichwort Phaselistener, in denen man zB. "gelockte" Objekte wieder freigibt etc. pp.

Hallo!?
Wer was wie?
Was muss ne Navi mehr machen als navigieren und was für "geblockte" Objekte.
Klingt irgendwie nach ner Antwort "ich hau mal mit paar Schlagwörter rum".

PhaseListner is eh kack weil um sicherzustelle, dass auch after gecallt wird alle Exceptions geschluckt werden.
Naja denk is n API Design Fehler oder evt nur n Impl Fehler (beziehs jetzt mal nur uff Mojarra)



> POST Navigation ist der Standard, GET reicht gerade mal um die Login Seite zu bekommen.

Absoluter Schwachsinn.
Wenn du schon was dazu bringst, dann aba bitte argumentativ

 

[maki]

Hallo!?

Hallo dich selbst...

Was muss ne Navi mehr machen als navigieren und was für "geblockte" Objekte.

"gelockt", nicht "geblockt"
Lesen kannst du doch wohl, oder ist das vielleicht die Ursache deiner Verwirrung?
Wenn ich einen Datensatz ändere, sollte dieser gelockt sein(zB "pessemistic offline locking", einfach mal googeln).
Das war ein Beispiel, gibt noch mehr.

Sobald ich einen Dialog betrete, werden im Hintergrund Dinge gemacht (Persitente Objekte richtig statt lazy laden, locking, etc.pp.), mit der Navi kann man das auch abbrechen, ein einfacher Link reicht vielleicht für simple Anwendungen, für komplexere nicht mehr, für einfache Webseiten ist JSF nicht gedacht.

Klingt irgendwie nach ner Antwort "ich hau mal mit paar Schlagwörter rum".

Bei dir klingt das eher wie "hab zwar keine Ahnung, mache mich aber trotzdem wichtig, aber das dann sehr laut"

PhaseListner is eh kack weil um sicherzustelle, dass auch after gecallt wird alle Exceptions geschluckt werden.
Naja denk is n API Design Fehler oder evt nur n Impl Fehler (beziehs jetzt mal nur uff Mojarra)

Ähhh.. quatsch, vollkommener.

Absoluter Schwachsinn.
Wenn du schon was dazu bringst, dann aba bitte argumentativ

Argumentativ?
"Kack"
"Absoluter Schwachsinn"

Das nennst du Argumentativ? Oder meinst du streitsüchtig?

Ich warte immer noch auf deine Argumente, hab bis jetzt kein einziges gesehen.

 

[Terminator]

> gelockt", nicht "geblockt"
war nur n Schreibfehler


> streitsüchtig?
nö, das bringt doch nix


> Wenn ich einen Datensatz ändere, sollte dieser gelockt sein(zB "pessemistic offline locking", einfach mal googeln).
Seh da kein Argument.
Wenn Aktion eine Änderung durchführt dann POST.
Wenn Aktion nur den Datensatz lockt dann geht das auch mit nem GET.


> Ich warte immer noch auf deine Argumente, hab bis jetzt kein einziges gesehen.
Suchmaschinen, Bookmarken, Cachen


>> PhaseListner is eh kack weil um sicherzustelle, dass auch after gecallt wird alle Exceptions geschluckt werden.
> Ähhh.. quatsch, vollkommener
Gab da mal ne entscheindende Änderung und leider ne schlechte.
Glaub war von Version 1.1 auf 1.2, musste einfach mal probieren.
Hier noch n Auszug aus der Spezifikation.

********
Section 11.3. PhaseListener

The beforePhase() method is called before the standard processing for a particular phase is performed, while the afterPhase() method is called after the standard processing has been completed. The JSF implementation must guarantee that, if beforePhase() has been called on a particular instance, then afterPhase() will also be called, regardless of any Exceptions that may have been thrown during the actual execution of the lifecycle phase. For example, let’s say there are three PhaseListeners attached to the lifecycle: A, B, and C, in that order. A.beforePhase() is called, and executes successfully. B.beforePhase() is called and throws an exception. Any exceptions thrown during the beforePhase() listeners must be caught, logged, and swallowed. In this example, C.beforePhase() must not be called. hen the actual lifecycle phase executes. Any exceptions thrown during the execution of the actual phase must not be swallowed. When the lifecycle phase exits, due to an exeception or normal termination, he afterPhase() listeners must be called in reverse order from the beforePhase() listeners in the following manner. C.afterPhase() must not be called, since C.beforePhase() was not called. B.afterPhase() must not be called, since B.beforePhase() did not execute successfully. A.afterPhase() must be called. Any exceptions thrown during the afterPhase() liseteners must be caught, logged, and swallowed.
*******