xnap-commons-devel

[XNap-Commons-Devel] Compeltion Architektur

[Steffen P. <ste...@gm...>]

Hi,

ich habe mir gerade die Architektur des Completion Packages angeschaut. All=
es=20
sehr sch=F6n dokumentiert und sehr lesbarer Code ;). Die Idee, Class Objekt=
e=20
f=FCr die Completion modes zu verwenden und per Reflektion auf ein statisch=
es=20
=46eld zuzugreifen finde ich allerdings nicht so sch=F6n. Ich sehe auch kei=
nen=20
Grund warum das Completion Objekt eine Liste von CompletionMode Objekten=20
kennen sollte.=20

Hier w=E4re IMHO eine Factory die optimale L=F6sung. Dort k=F6nnten auch=20
zuzs=E4tzliche Modes mit einem Klassen- und Displaynamen registriert werden=
,=20
ohne das es n=F6tig w=E4re Completion abzuleiten. Ein gutes Beispiel f=FCr =
eine=20
solche Factory ist javax.swing.UIManager.

Kommentare?

Steffen

=2D-=20
Steffen Pingel - ste...@gm... - http://steffenpingel.de

Re: [XNap-Commons-Devel] Compeltion Architektur

[Felix B. <bf...@gm...>]

On Tuesday 19 April 2005 12:56, Steffen Pingel wrote:

> Die Idee, Class
> Objekte für die Completion modes zu verwenden und per Reflektion auf ein
> statisches Feld zuzugreifen finde ich allerdings nicht so schön. 

Das mit dem Feld ist zugegebenermaßen ein Hack und hat mir auch nicht behagt. 
Bezieht sich Dein Unbehagen auch auf die Tatsache, daß reflection benutzt 
wird?

> Ich sehe 
> auch keinen Grund warum das Completion Objekt eine Liste von CompletionMode
> Objekten kennen sollte.

Das CompletionModeMenu kann dann das completion objekt nach den verfügbaren 
CompletionModes fragen, so könnte man das sogar noch für jedes einzelne 
Completion objekt ändern, das ist mir aber erst gekommen, als ich mit dem 
CompletionModeManager angefangen habe. 

> Hier wäre IMHO eine Factory die optimale Lösung. Dort könnten auch
> zuzsätzliche Modes mit einem Klassen- und Displaynamen registriert werden,
> ohne das es nötig wäre Completion abzuleiten. 

Das ist wahr, die Completion abzuleiten, um einen neuen Mode hinzuzufügen ist 
schlecht. Habe mal einen rudimentären CompletionModeManager angehängt. Wenn 
Ihr dagegen keine Einwände habt, würde ich versuchen, ihn noch fertig zu 
machen und zu integrieren.

Feix

-- 
Try Debian GNU/Linux!
http://www.felix.beldesign.de/

Re: [XNap-Commons-Devel] Completion Architektur

[Steffen P. <ste...@gm...>]

Hi,

> Bezieht sich Dein Unbehagen auch auf die Tatsache, da=DF reflection
> benutzt wird?

Nein, in keinster Weise. Nur geh=F6rt die Instanzierung IMHO nicht in die=20
Completion Klasse, sondern in eine Factory oder den caller (soweit ich es=20
gesehen habe wurden bisher die Exceptions auch einfach verschluckt).

> Das CompletionModeMenu kann dann das completion objekt nach den verf=FCgb=
aren
> CompletionModes fragen, so k=F6nnte man das sogar noch f=FCr jedes einzel=
ne
> Completion objekt =E4ndern, das ist mir aber erst gekommen, als ich mit d=
em
> CompletionModeManager angefangen habe.

Auch hier ist IMHO die Factory die bessere Stelle um nach Modes zu Fragen, =
da=20
die Modes nicht mit dem Completion Objekt Verkn=FCpft sind. Wenn der Benutz=
er=20
die CompletionModes beeinflussen m=F6chte, muss er eben selbst ein Popup=20
instanzieren.

> Habe mal einen rudiment=E4ren CompletionModeManager angeh=E4ngt.
> Wenn Ihr dagegen keine Einw=E4nde habt, w=FCrde ich versuchen, ihn noch f=
ertig
> zu machen und zu integrieren.

Sieht sehr gut aus, go ahead ;).

Steffen

=2D-=20
Steffen Pingel - ste...@gm... - http://steffenpingel.de