benutzen XPage Entwickler eigentlich die "roten Felder"?

[flaite]

In den Notes-Anwendungen, die ich in meinem Fall vor vielen Jahren betreut hab, gabs oben immer einen Bereich "rote Felder", die man mit einem Handgriff ausblenden konnte (notes.ini Variabe oder whatever, kann mich nicht mehr erinnern). Jedenfalls konnte man die für die Entwicklung immer einblenden.

Heute morgen hat ich bei meiner richfaces4, jsf2, csi, ejb lite, jpa2 mit eclipse-link Anwendung eine gute Idee: In den komplexeren JSF-Facelets (sozusagen masken und ansichten in jsf) hab ich nun eine erste Tabelle mit einem ROTEN FELD Ich bin völlig hin und weg. Nicht nur wenig nostalgischer Rührung, sondern das macht echt SINN. Die Dinger halten nicht nur Client-State, sondern eben auch Server-State.
Das funktioniert deshalb, weil in RichFaces4 der Ajax Support gut genug ist, dass eine Web Anwendung sich ausreichend wie eine Client Server anfühlt.  

LANGE REDE KURZER SINN: BENUTZT MAN BEI XPAGE ENTWICKLUNG EIGENTLICH AUCH ROTE FELDER?

[Tode]

Sorry, aber ich muss schmunzeln: Die Eigenschaft "Farbe=Rot" hat erstmal keinerlei Einfluss auf die Sichtbarkeit eines Feldes.... Das was Du meinst ist eine "Stille Übereinkunft" unter Notes- Entwicklern: Wenn man ein Feld per Hide- When versteckt (z.b. nur Sichtbar für alle, die eine bestimmte Rolle haben), dann gibt man diesem Feld die Farbe Rot und die Schriftgrösse 8px... So ist für jeden anderen Entwickler sofort im Designer sichtbar: Dieses Feld ist verborgen...

Natürlich kann man auch in xPages mit Hilfs- Variablen / Hilfs- Feldern arbeiten, und der "klassische" Entwickler wird auch hier wieder auf die Farbe rot zurückgreifen, aber in meinen bisherigen Entwicklungen habe ich sie definitiv wesentlich seltener benutzt als in der klassischen Notes- Entwicklung, weil man sowieos viel mehr "Code" schreibt und solche Hilfskonstrukte einfach seltener braucht....

[flaite]

Ich finde das Idiom absolut genial. Weiss natürlich auch, dass das auf einer Übereinkunft beruht.
1999 bis 2002 hab ich ziemlich komplexe Notes und Notes-Web Anwendungen geschrieben.

Eins meiner großen Probleme mit realer JSF Projekten ist, dass State Abfragen von komplexeren Seiten gewohnheitsmässig über mehrere States der Backing Beans abgefragt werden, statt Sie in einem enum-Property zu bündeln, was echt deutlich übersichtlicher ist.

Das kann in das rote Feld geschrieben werden.
Mit der Rolle hast Du mich auf eine Idee gebraucht.
 
Meinst Du das mit dem "viel mehr code schreiben" ernst?
Ich seh aktuell den Trend zu immer weniger code.
Der Junior schreibt Zeilen, der Senior löscht sie.

[Tode]

Nun ja: Nehmen wir nur mal ein paar Beispiele:

a) In der "klassischen" Entwicklung ist das ein Häkchen in den View- Eigenschaften, dass solche Kategorien "Test\Testunter\nocheintest" automatisch eingerückt werden. In xPages muss ich mir das einrücken selbst schreiben -> Viel Code

b) Für eine Klassische Ordner- Navigation / Ansichts- Navigation in einer Notes- Datenbank brauche ich nur ein Outline, und da lege ich für jede Ansicht einen Eintrag an. In xPages brauche ich für jede Ansicht einen Punkt in einer xPage und dann die passende xPage und oder Custom Control um die anzuzeigen... und Code, der jeweils zur richtigen Seite umleitet...

c) NamePicker: Feldeigenschaft im klassichen Notes, in xPage gibt es x Ansätze, aber jeder mit nem Haufen Menge Code...

JA, es gibt in xPages für jeden der Punkte u.U. bessere / modernere Methoden, so dass man das alles gar nicht braucht... Aber trotzdem sollte die Tendenz klar sein...

[flaite]

In JEE geht der Trend zu deutlich weniger Code. Zum Teil theoretisch.

Dageben arbeiten verschiedene Gruppen.

• Architekten, die stolz auf ihr Informatikstudium aus den 70ern sind und der Meinung sind, dass sich "im Grunde nichts geändert hat", aber nur weil sie jede moderne Arbeitserleichterung als gefährliche Magie ansehen.
• Entwickler, die ihre Ignoranz gegen alle neuen Entwicklungen seit ihrem Studium mit dem Argument "Inder-Sicherer-Code" schreiben, abblocken
• Entwickler, die in ihrem Lieblings-Framework die letzte Ecke und den übelsten workaround kennen, und auf diesem beharren, obwohl das Framework seit 3 Jahren nicht mehr weiterentwickelt wird. Inzwischen haben sie darauf aufbauend so viel draufgesetzt, dass man das kaum noch ersetzen kann. Sie beschäftigen sich dann 3 Monate mit einem feature, für die es in ALLEN modernen Konkurrenz-Frameworks eine Standard-Komponente gibt.
• Völlig verrückte in house Komponenten-Bibliotheken, deren Verwendung nur politisch erklärt werden kann.