http://www.nnseek.com/e/de.comp.lang.java/ Posts for de.comp.lang.java Fri, 26 Dec 2008 15:26:04 PST http://www.nnseek.com/ http://www.nnseek.com/img/64.png 64 64 NNSeek http://www.nnseek.com/e/de.comp.lang.java/toolbox_window_139186294t.html http://www.nnseek.com/e/de.comp.lang.java/toolbox_window_139186294t.html
ich benötige ein Dialogfenster welches nicht-modal ist, keinen Button in der
Taskbar (auch nicht in der ALT-TAB Liste) hat und das für Tastatureingaben
vom Benutzer geöffnet ist (also kein JDialog mit
setFocusableWindowState(false);).

Also sowas wie ein Toolbox-Fenster.
Gibts da was ? Bisher bin ich mit JFrame/JDialog/JWindow nicht
weitergekommen.


Danke und Grüße

Posted In: de.comp.lang.java

no comments

Reply

]]> Fri, 26 Dec 2008 15:26:04 PST http://www.nnseek.com/e/de.comp.lang.java/jdom_genaues_einlesen_schreiben_von_mehren_zwische_139168118t.html http://www.nnseek.com/e/de.comp.lang.java/jdom_genaues_einlesen_schreiben_von_mehren_zwische_139168118t.html einlesen/schreiben kann:


laber 1
laber 2
laber 3
laber 4
laber 5

Posted In: de.comp.lang.java

1 Comment

Reply

]]> Fri, 26 Dec 2008 11:12:52 PST http://www.nnseek.com/e/de.comp.lang.java/client_cert_139144566t.html http://www.nnseek.com/e/de.comp.lang.java/client_cert_139144566t.html
ich möchte via Zertifikat eine Client-Auth durchführen.

Rufe ich die Webanwendung vom selben Rechner aus auf, wie dem wo der Tomcat
läuft, fkt das.
Von einem anderen Rechner aus wird dasselbe Zertifikat nicht akzeptiert.

Woran kann das liegen?

Danke

Posted In: de.comp.lang.java

1 Comment

Reply

]]> Fri, 26 Dec 2008 07:24:41 PST http://www.nnseek.com/e/de.comp.lang.java/frage_zu_treeset_139120502t.html http://www.nnseek.com/e/de.comp.lang.java/frage_zu_treeset_139120502t.html
Patrick Roemer schrieb:
> Responding to Michael Rauscher:
>
>>> moeglichen Verletzung sind fuer Comparable genau so festgelegt. Daher
>>> ist es nicht noetig, das bei jeder Implementierung zu wiederholen.
>> Hier sehe ich die Dinge einfach etwas anders. Ich finde nicht, dass die
>> NPE wirklich dokumentiert wäre. Es gibt zwar einen Hinweis auf eine
>> mögliche NPE, dieser befindet sich aber auf Typ-Ebene und enthält den
>> Zusatz "should". Auf Methodenebene wird eine mögliche NPE überhaupt
>> nicht erwähnt.
>
> | NOTE: If possible, document the general null argument behavior at the
> | package or class level, such as causing a
> | java.lang.NullPointerException to be thrown. Deviations from this
> | behavior can then be documented at the method level.
> http://java.sun.com/j2se/javadoc/writingapispecs/index.html#method
>
> Was das "should" angeht: Es ist kein "SHOULD", und die Verwendung der
> strikten RfC-Nomenklatur ist in Javadocs sowieso eher unueblich. Ich
> lese das im normalen Sprachgebrauch als "das sollte man (wirklich) machen".

Gerade im normalen Sprachgebrauch ist "sollte" die abgeschwächte Form
von "soll". Daher:

>> Ich verstehe dies somit als Implementierungshinweis ohne
>> Verbindlichkeitscharakter,
>
> IBTD. Dann haetten sie es ja gleich weglassen koennen.

Das wäre IMO auch besser gewesen. Für Comparable selbst gilt die
Vorbedingung nicht. Statt dessen wird hier eine Empfehlung (oder von mir
aus auch der Hinweis auf einen Regelfall) für mögliche Implementierungen
abgegeben. Wem soll die Aussage denn was bringen?

Gut, nun lässt sich argumentieren, dass auf diese Weise der Regelfall
nur einmal zu dokumentieren ist. Das entspricht aber dem gleichen
Argument, das Leute anführen, die Vererbung zur Code-Ersparnis
einsetzen. Einen echten Nutzen dahinter kann ich nicht erkennen.

Ich möchte beim Lesen der Doku der jeweiligen Klasse/Methode wissen, was
passiert und mich nicht erst durch die Klassenhierarchie hangeln müssen,
ob irgendwo - vielleicht auch noch auf Paketebene - ein Hinweis auf
einen Regelfall gegeben wurde, der nun zu berücksichtigen wäre (oder
vielleicht auch nicht, da er ggf. im Widerspruch zum Regelfall der
implementierenden Klasse steht).

Aber: von mir aus kann das natürlich jeder halten wie er will.

>> Abgesehen davon kann die NPE aus unterschiedlichen Gründen auftreten.
>> Bei Pauls Implementierung noch dazu in der selben Zeile. Und ggf. sucht
>> man dann erstmal vergeblich danach, warum anderes == null galt :)
>
> Daran aendert sich doch nichts, wenn die NPE fuer den einen der beiden
> Gruende redundant dokumentiert wird. (Und den anderen Grund sollte man
> wiederum nicht dokumentieren, da implementierungsspezifisch.)

Sorry, habe vergessen anzumerken, dass das die Begründung für die von
mir bevorzugte IAE ist.

Gruß
Michael

Posted In: de.comp.lang.java

1 Comment

Reply

]]> Fri, 26 Dec 2008 02:26:49 PST http://www.nnseek.com/e/de.comp.lang.java/modelle_als_singleton_139064438t.html http://www.nnseek.com/e/de.comp.lang.java/modelle_als_singleton_139064438t.html
ich stelle mal voran, warum ich überzeugt bin vom PM.

In der OO-Gruppe bin ich auf folgenden Thread gestoßen
http://groups.google.com/group/comp.object/browse_frm/thread/419ac812e1e9446e/8b0a8e7357122423...#8b0a8e7357122423
Er ist etwas länglich, aber dort haben viele beigetragen,
die von der Sache etwas verstehen. Was bei mir hängen
geblieben ist, dass man eine GUI zuerst einmal ohne
Rücksicht auf die UI Komponenten programmieren sollte.
Fowler betont in erster Linie immer die getrennte
Testbarkeit der UI, aber dies ist für mich nicht der
wichtigste Punkt. Ich kann mich auf ein logisches
Abbild des UI konzentrieren und verstricke nmich nicht
in der Komplexität des Toolkits. Dies schließt ein
Selektionen, bis hin zu Farben für Error Zustände.
Das Modell im PM ist für mich +ein+ Modell in Form
eines Baums. Die verschiedenen Windows und deren
Panels verbinden sich zu Knoten des Baums.

Nicht nur die UI Daten, sondern die gesamte Ablauf-
logik befindet sich in diesem Modell (nicht domain
model sondern application model). Ich benutze nicht
einmal die Modell Klassen von Swing. Die Swing
Komponenten mit ihren Modell Klassen sind für mich
Bestandteile der View. Warum? Die Swing Komponenten
arbeiten eng mit ihren Modell Klassen zusammen. Es
findet ein reger Ereignisstrom vom Modell zum UI
statt. Dies möchte ich aber nicht zwischen dem
Presentation Model und seiner View haben. Hier bin
ich grobgranular und arbeite im Zyklus der Anwender
Aktionen. Diese gehorchen immer dem gleichen
Rhythmus, egal ob ein einfacher key typed oder
eine komplexe Änderung durch den Apply Button auf ein
Window. Zuerst wird das Modell mit allen seinen
Seiteneffekten verändert und abschließend nur
+eine+ Notification in Richtung der Views geschickt.
Diese synchronisieren sich jeweils auf den neuen
Zustand der Modells. Die Views dürfen natürlich
nicht mit erneuten Änderungen des Modells reagieren.
In diesem Fall ist der Observer Mechanismus gut zu
kontrollieren. Aber wie Du weiter unten erwähnst
ist er in vieler Hinsicht tückisch.

Nachteil ist die doppelte Datenhaltung. Im Client
aber oft nicht so tragisch.

Aber auch bei meinem Vorgehen gibt es genug Fallstricke.
Hier ein Beispiel. Selektiert der Anwender per Maus
eine Checkbox in einer neuen Zeile einer JTable habe
ich zwei logische Ereignisse ausgelöst. Die Selektion
der neuen Zelle und die Zustandsänderung der Checkbox.
Sie werden hintereinander ausgelöst, bevor ich mit
einer Notification auf das erste Ereignis der Selektion
antworten kann. Dies könnte theoretisch aber dafür
sorgen, dass die Zustandsänderung der Checkbox in diesem
Fall gar nicht mehr möglich wäre. Diese Art von
Ereignis Sequenzen ist zwar eher selten, aber besonders
mit den Sequenzen in der JTable hatten wir so unsere
Probleme. Sie werden auch nicht alle auf dem Callstack
ausgeführt, sondern teilweise gequeued. Dann weiß man
bei Swing nicht mehr so einfach, vom wem ein Ereignis
ausgelöst wurde.

...
> ich hab mir ziemlich viel von diesen Ansätzen durchgelesen, bin jedoch
> bei verschiedenen Projekten immer wieder auf die Schwierigkeit gestoßen,
> wo trenne ich die Logik von der Präsentation. Man kann sich bei fast
> allen Aktionen die Frage stellen: Lieber ins M oder ins V oder ins C
> reinpacken?
Bei PM kann man dies recht einfach beantworten. (Fast) alles gehört
ins Modell.

> So half mir MVC nicht wirklich weiter, bis ich bei Passive
> View hängen geblieben bin und ich damit die Anwendung ziemlich klar
> trennen kann: Die View ist simple, keine Logik, nur Daten übergeben und
> anzeigen, das Model ist auch simple, nur Daten übergeben, speichern und
> wieder abfragen. Einzig der Controller beinhaltet die Logik, kein
> Observer-Pattern was den Code für Aussenstehende unverständlicher macht.
s.o.

> Fowlers Ansätze (http://martinfowler.com/eaaDev/) habe ich alle für
> einen Vortrag mal implementiert, natürlich wieder nur in einfachen
> Beispielen - was nicht immer hilfreich ist.
Ja, schade das Fowler bei dem Thema nicht mehr weiter macht. Nicht
nur wir haben Probleme im Detail mit den Abläufen.

>
> Die Ideen von Karsten hab ich auch schon mehrfach gelesen, ich hab nur
> noch keinen Code gesehen, an dem ich das mal am "lebenden Objekt"
> untersuchen konnte. Wenn jemand ein entsprechendes OpenSource-Projekt
> kennt...
Ja, bin auch interessiert.
Viele verfügbare Beispiele sind stark an das entsprechende Toolkit
gebunden
Swing, Eclipse, NetBeans.

> Eigentlich verwende ich bereits MVP, nur dass die View
> ausschließlich durch den Controller/Presenter verändert wird (siehe auch
> Karsten's Folie 43 - exakt was ich implementiere). Meine Fragen zielten
> aber auf 2 Dinge ab:
Ja, hab Dich etwas vom Thema abgebracht. Bin aber sehr an Erfahrungen
mit anwendungsweiten Konzepten interessiert.

>
> a) wie greifen die Swing-Actions, die an die View angekoppelt sind, auf
> die Modelle zu? Das scheint mittlerweile gelöst, denn diese greifen auf
> kein Modell zu, sondern verwenden Routinen des Controllers/Presenters,
> um die Modelle anzupassen und die View wiederum zu aktualisieren. Diesen
> Zugriff hab ich noch weiter entkoppelt über Interfaces, Command-Pattern...
>
> b) hat die Applikation eine Vielzahl z.B. > 50 solche MVP-Konstrukte,
> wie interagieren diese miteinander? Observer? Die Presenter
> untereinander? Das habe ich noch nicht zufriedenstellend gelöst.
>
> Vielleicht ist auch meine Wortwahl falsch:
>
> * die View ist keine JComponent, es ist ein einfaches Objekt, welches
> ein oder mehrere JComponents erzeugt und eine vereinfachte Schnittstelle
> darauf anbietet, welche der Controller/Presenter verwendet
So stark vereinfachen kannst Du sie doch gar nicht. Der
Controller muß doch diese dummen Views steuern, oder?

>
> * der Controller/Presenter ist ein Objekt, welches die
> Applikations-Logik beinhaltet für die zugeordnete View (und nur für
> diesen kleinen Teil, z.B. ein JTree). Muss der Controller auf andere
> Teile der Applikation zugreifen fangen meine Probleme an...
Gegen einen so mächtigen Controller habe ich Vorbehalte. Er ist
ein Mediator in beide Richtungen. Er muß Details der View
kennen und einen komplexen Update des Modells durchführen.
Dazu hält er noch Status. Dies kann aus meiner Sicht nicht
zu einer übersichtlichen Struktur der Controller Klassen
führen. Sie sind zu mächtig.

Das ganze führt dann zu einem Mediator, der alle Controller
verbinden kann oder es führt zu Responder Chains, die bestimmt
nicht einfach sind. Aber vielleicht irre ich mich da.

>
> * das Modell ist das lokale Datenobjekt für den Controller/Presenter und
> dessen zugeordnete View. Es hält die Informationen, die die View
> anzuzeigen hat und nichts mehr. Beeinflussen andere Teile der
> Applikation die hier gespeicherten Daten, hab ich auch dafür noch keine
> "schöne" Lösung.
Wie oben erwähnt, ich benutze +ein+ zusammenhängendes Modell.
Oberhalb der elementaren Komponenten wirst Du auch irgendetwas
Koordinierendes brauchen.

>
> Ein Fachdaten-Modell hab ich noch nicht implementiert, das setzt sich
> aber aus allen relevanten Informationen der Teildaten-Modelle zusammen.
> Hier könnte ich die notwendigen Änderungen an eine tiefere Schicht
> weitergeben und von dort per Observer beziehen. Damit ändere ich
> allerdings die "lokalen Datenobjekte" durch eine externe Quelle, was bei
> passive View dazu führt, dass die View asynchron zum Modell ist (da der
> Presenter ja die Änderung nicht mitbekommt). Dann hilft z.B. das der
> Controller das lokale Daten-Objekt überwacht (schlägt Fowler vor).
>
> Nun schreibt derselbe Fowler aber, man soll Observer-Ketten vermeiden,
> weil die Applikation zu kompliziert zu durchschauen ist - es ist zum
> verrückt werden...
>
> Man merkt dass ich in kleinen Schachteln denke und diese in immer
> größere schachteln verpackt werden, was am Ende die Gesamt-Applikation
> ergeben soll. Leider hapert es bei der Inter-Schachtel-Kommunikation... :-)
Ich glaube, das ist der springende Punkt. Bottom-up kommt
man wahrscheinlich nicht zu einem einfachen und überschaubaren
Gesamtkonzept. Für jedes Einzelproblem gibt es immer eine
Lösung. Aber dies führt in der Summe nicht zu einem schönen
Konzept für die gesamte Applikation.

Ich habe für mich versucht die Aktionen des Anwenders als
stabile Basis zu verwenden. Die UI reagiert auf eine Aktion
des Benutzers, verändert ihren Zustand und nimmt einen
neuen konsistenten Zustand ein. Dann kommt die nächste
Aktion. So funktioniert meine Anwendung, aber dies gilt
bestimmt nicht allgemein.

Gruß
Wolfgang R.

Posted In: de.comp.lang.java

no comments

Reply

]]> Thu, 25 Dec 2008 12:10:23 PST http://www.nnseek.com/e/de.comp.lang.java/capture_replay_tool_f9r_regressionstests_gesucht_139052918t.html http://www.nnseek.com/e/de.comp.lang.java/capture_replay_tool_f9r_regressionstests_gesucht_139052918t.html > Olaf Foellinger wrote:
>>> Welche GUI Technologie?
>> Rich clients, Eclipse/RCP und Trend-Framework von GEBIT (http://www.gebit.de/).
>
> Das ist alles SWT oder? Mit Rational Tester oder Eclipse TPTP oder SWTBot
> soll das gehen. OIO hatte dazu auch nen Artikel, das stellt weitere
> kommerzielle Tools vor: http://www.oio.de/eclipse-rcp-test-artikel.htm
>
> Gruss
> Bernd
>

Welche Tools könnt ihr denn empfehlen, wenn man Swing Applikationen
testen möchte?

Ein Recording Modus wäre mir da sehr lieb sowie die Integration in JUnit.

Uwe

--
Email-address is valid but never read. Visit
www..de for my contact details.

Posted In: de.comp.lang.java

1 Comment

Reply

]]> Thu, 25 Dec 2008 08:55:49 PST http://www.nnseek.com/e/de.comp.lang.java/capture_replay_tool_f9r_regressionstests_gesucht_139052662t.html http://www.nnseek.com/e/de.comp.lang.java/capture_replay_tool_f9r_regressionstests_gesucht_139052662t.html > Olaf Foellinger wrote:
>>> Welche GUI Technologie?
>> Rich clients, Eclipse/RCP und Trend-Framework von GEBIT (http://www.gebit.de/).
>
> Das ist alles SWT oder? Mit Rational Tester oder Eclipse TPTP oder SWTBot
> soll das gehen. OIO hatte dazu auch nen Artikel, das stellt weitere
> kommerzielle Tools vor: http://www.oio.de/eclipse-rcp-test-artikel.htm
>
> Gruss
> Bernd
>

Wie schaut's denn aus mit reinen Swing-Anwendungen? Oder mit Integration
in Netbeans?

Uwe

--
Email-address is valid but never read. Visit
www..de for my contact details.

Posted In: de.comp.lang.java

no comments

Reply

]]> Thu, 25 Dec 2008 08:53:03 PST http://www.nnseek.com/e/de.comp.lang.java/the_world_live_chat_sex_web_cams_and_amazing_video_138868854t.html http://www.nnseek.com/e/de.comp.lang.java/the_world_live_chat_sex_web_cams_and_amazing_video_138868854t.html cams & chat online.

Straight, Gay, Lesbian, Swingers, and more.

Get sexy and broadcast your own cam. Chat for free.

MOre... [b] http://modfxmodelsxxx.blogspot.com/ [/b]

>>>>>>>>> NOTE:>To GET BEST Sex Advice for ALL <<<<<<<<<<

http://join.digitaldesire.com/track/viijaysaini:pay_join:ddgirls/

http://germanfriendfinder.com/go/g1029865-ppc

http://adultfriendfinder.com/go/g1029865

http://lesbianpersonals.com/go/g1029865

http://outpersonals.com/go/g1029865

http://passion.com/go/g1029865

http://alt.com/go/g1029865

Posted In: de.comp.lang.java

no comments

Reply

]]> Mon, 22 Sep 2008 20:52:42 PDT http://www.nnseek.com/e/de.comp.lang.java/verst5ndnissfrage_wo_geh9rt_was_hin_138724982t.html http://www.nnseek.com/e/de.comp.lang.java/verst5ndnissfrage_wo_geh9rt_was_hin_138724982t.html
ich weiss, es wurden sicherlich schon viele Fragen dieser Art gestellt,
jedoch bin ich mir immer noch unsicher wo ich was (3-n Schichten Modell)
ablegen soll.

Ich habe ein umfangreiche Swing Maske.
Diese habe ich in 4 Klassen aufgeteilt.
In der Hauptklasse werden diese zusammengeführt.
Die events für alle die Dinge der Maske habe ich in eine eigene Klasse
ausgelagert.
Die Logik dieser Maske (ja, es gibt auch "Maskenlogik") auch in einer
eigenen Klasse.

Nun habe ich das Problem, dass alles ein wenig unüberschaubar wird, weil
ich in der Hauptklasse alle instanzen erzeugen und überall hin
"mitschleppen" muss.

Gibt es bessere Ansätze ? (Klar gibt es die, meine Frage zielt auf
Lösungen :-) )

Hans

Posted In: de.comp.lang.java

5 Comments

Reply

]]> Mon, 22 Sep 2008 09:34:50 PDT http://www.nnseek.com/e/de.comp.lang.java/god_of_gifts_4_u_138708086t.html http://www.nnseek.com/e/de.comp.lang.java/god_of_gifts_4_u_138708086t.html GAMES HEALTH EATING TIPS HAND REFLEXORGLY NATURE AND JESUS BEAUTIFUL
PICS
http://www.godofgifts.blogspot.com/

Posted In: de.comp.lang.java

no comments

Reply

]]> Mon, 22 Sep 2008 08:24:08 PDT