[Java] Soort van SessionContext in Swing

[Standeman]

Sinds enige tijd ben ik bezig mijn kennis van Java wat te verbreden door een Swing applicatie te bouwen. Best leuk, aangezien ik voor mijn werk eigenlijk alleen maar web applicaties bouw met JSP / Struts.
Nou komt er een lastig gedeelte, ik ben altijd gewend aan het request / reply karakter van het web en ook de SessionContext waar je zo makkelijk variabelen in stopt die je in de rest van je applicatie kan gebruiken omdat ik in elke servlet de session context heb waar alles staat.

Nu ik met Swing bezig ben heb ik niet direct een plek waar ik variabelen kwijt kan die ik wel in verschillende panels, frames, etc goed kan gebruiken. Een voorbeeld is mijn User object. Hier wil ik bij kunnen wanneer ik het zelf wil.

1 manier om het op te lossen is om aan elke JPanel / JFrame object dat ik creeer een extra contstructer toe te voegen waarbij ik b.v. een ApplicationContext object mee geef waarin o.a. het User object in zit.
Aangezien dat wel wat betekend (het aanpassen van al mijn GUI objecten) vind ik het een beetje te veel werk om er "zomaar" aan te beginnen omdat ik even geen andere manier kan bedenken. (Ja ik weet het.. ik had er aan moeten denken toen ik er aan begon )

Hoe lossen jullie het op? Objecten die je eigenlijk in heel je applicatie nodig hebt? Hoe maak je die bekend bij de verschillende frames e.d.

Ik ben benieuwd! Is er een heilige graal voor dit probleem?

[Janoz]

Een applicatie is over het algemeen een single user iets. Je hebt dus niet meerdere gebruikers die dezelfde instantie draaien. Hierdoor is er geen verschil meer tussen session scope en application scope. Eventueel zou je het op kunnen lossen met een static object.

In principe hoef je ivm j2ee nauwelijks anders te werken. Via het MVC principe kun je ook keurig een applicatie bouwen. In plaats van request krijg je echter eerder met events te maken. Je moet je oplossing echter niet in swing zoeken. Swing is alleen maar voor de view. Ik krijg namelijk een beetje het idee dat je de view erg met je buisness logic aan het koppelen bent.

[PhoneTech]

Ach...er zijn altijd wel meerdere heilige gralen te vinden voor dit probleem.

Ik gebruik gewoon een singleton class die ik in het begin initialiseer met oa het userobject, server urls en nog meer meuk die ik in de hele applicatie gebruik. Werkt prima voor wat ik nu aan het doen ben

[Standeman]

PhoneTech schreef op vrijdag 02 september 2005 @ 10:23:
Ach...er zijn altijd wel meerdere heilige gralen te vinden voor dit probleem.

Ik gebruik gewoon een singleton class die ik in het begin initialiseer met oa het userobject, server urls en nog meer meuk die ik in de hele applicatie gebruik. Werkt prima voor wat ik nu aan het doen ben

Daar ben ik dus min of meer ook mee bezig.. aan de hand van mijn ApplicationContext object waar ik alle meuk in aan het stoppen ben.. Ik zat me alleen nog af te vragen hoe ik dat object kenbaar ga maken bij al mijn Frames en Panels e.d. Meegeven in de constructor, setten via een methode, een superobject waar de frames en panels van afgeleid worden (soort van ApplicationComponent, afgeleid van JComponent waar ik het contextObject erin zet?) of een combinatie er van?

[ronaldmathies]

Je moet eens kijken naar het singleton pattern, dan hoef je deze niet mee te geven aan allerlei classen e.d.:

http://java.sun.com/devel...patterns/Terminology.html

[Standeman]

ronaldmathies schreef op vrijdag 02 september 2005 @ 12:28:
Je moet eens kijken naar het singleton pattern, dan hoef je deze niet mee te geven aan allerlei classen e.d.:

http://java.sun.com/devel...patterns/Terminology.html

hmmm.. een singleton is denk ik wel de beste keuze hiervoor. (kende het pattern al.. alleen nog niet om 'm hier te gaan gebruiken...). Ik gebruik het al wel voor mijn ConnectionManager....

thanx allemaal...

[ Voor 7% gewijzigd door Standeman op 02-09-2005 13:30 ]

[Verwijderd]

Nou eigelijk is het helemaal geen goede keuze aangezien het een single user applicatie betreft.

[Standeman]

Verwijderd schreef op vrijdag 02 september 2005 @ 13:35:
Nou eigelijk is het helemaal geen goede keuze aangezien het een single user applicatie betreft.

Hoe zou jij het dan oplossen?


Nog even wat anders. Ik gebruik in mijn applicatie meerdere instanties van dezelfde ComboBox. Deze combox is een afgeleid van een normale combobox alleen worden er wat waarden ingelezen vanuit de DB en zijn er wat functies toegevoegd. Is het handig om hier een singleton van te maken.. Dan hoef ik ze namelijk niet apart te initialiseren indien er een waarde wijzigt. Of is het misschien handiger om ze een listener te geven welke voor een soort van reinitialiseEvent luisterd? (ik snap events nog niet voor 100%, dus dat laatste wordt wel een stuk lastiger).

[ronaldmathies]

Verwijderd schreef op vrijdag 02 september 2005 @ 13:35:
Nou eigelijk is het helemaal geen goede keuze aangezien het een single user applicatie betreft.

Ja dus? wat is dan de oplossing naar jouw idee?
Wat maakt het trouwens uit of het single user is? dan is het juist ideaal om van een singleton pattern gebruik te maken.

[Verwijderd]

Je hebt bij een single user applicatie een entry (controller) die de juiste instanties van klasses aanmaakt en delegeert/propageert naar de juiste klassen. Zodoende is een singleton overbodig.

[Standeman]

Verwijderd schreef op vrijdag 02 september 2005 @ 14:09:
Je hebt bij een single user applicatie een entry (controller) die de juiste instanties van klasses aanmaakt en delegeert/propageert naar de juiste klassen. Zodoende is een singleton overbodig.

Maar de applicatie waar ik aan werk is niet helemaal single user. Er zijn alleen geen concurrent users. Dus een controller die de juiste classes propageert dient dit misschien wel vaker te doen dan 1 maal in de lifecycle van de applicatie en heeft daarom input nodig voor elke user hij de data moet propageren. Welke user bezig is moet dus ergens in de context aanwezig zijn. Aan de hand van de singleton, kan je dit bijhouden.

lijk mij..

[Verwijderd]

Standeman schreef op vrijdag 02 september 2005 @ 14:18:
Maar de applicatie waar ik aan werk is niet helemaal single user.

Welke user bezig is moet dus ergens in de context aanwezig zijn. Aan de hand van de singleton, kan je dit bijhouden.

You lost me here...

[Standeman]

Zie het als een soort van Windows 98.... 1 user tegelijkertijd kan maar aangelogd zijn, maar de user kan zich afmelden en een ander kan zich weer aanmelden... (voor de desktop, that is). Dus dezelfde instantie van applicatie wordt gebruikt door meerdere users, alleen niet tegelijkertijd.

De controller moet dus weten welke user is aangelogd indien er om info gevraagd wordt... Deze informatie wil ik dus gaan opslaan in een Singleton.. Volgens mij wel een goede manier om de gegevens van user bekend te maken over de verschillende classes welke hier gebruik van maken..

Elke keer wanneer de controller geinitaliseerd wordt, weet deze namelijk niet meer welke user is aangelogd. Dus het simpelste is het maken van een class welke maar 1 x geinitialiseerd kan worden.

[Verwijderd]

Dat is in mijn ogen toch echt een single user applicatie en daarbij is dus mijn vooorgaande verhaal van kracht.

[ravenger]

Standeman schreef op vrijdag 02 september 2005 @ 14:41:
Zie het als een soort van Windows 98.... 1 user tegelijkertijd kan maar aangelogd zijn, maar de user kan zich afmelden en een ander kan zich weer aanmelden... (voor de desktop, that is). Dus dezelfde instantie van applicatie wordt gebruikt door meerdere users, alleen niet tegelijkertijd.

Wat is et probleem hier dan? Er kan toch maar 1 user tegelijkertijd? single-user perhaps?

[TukkerTweaker]

Ik zie het grote nadeel van het gebruik van singletons niet zo.

[djengizz]

TukkerTweaker schreef op vrijdag 02 september 2005 @ 17:11:
Ik zie het grote nadeel van het gebruik van singletons niet zo.

Je applicatie is misschien niet multi-user maar wel multi-threaded (neem ik aan).
Het singleton Pattern kent synchronisatie anders zou het nooit thread-safe zijn.
M.a.w. als veel threads jouw singleton tegelijkertijd nodig hebben kun je wel eens een 'hangende GUI' krijgen.
Dus eigenlijk gewoon dezelde issues als in een multi-user omgeving

[Standeman]

djengizz schreef op vrijdag 02 september 2005 @ 19:34:
[...]


Je applicatie is misschien niet multi-user maar wel multi-threaded (neem ik aan).
Het singleton Pattern kent synchronisatie anders zou het nooit thread-safe zijn.
M.a.w. als veel threads jouw singleton tegelijkertijd nodig hebben kun je wel eens een 'hangende GUI' krijgen.
Dus eigenlijk gewoon dezelde issues als in een multi-user omgeving

Ahhaaa... Nu wordt het interessant..

Mijn applicatie is zelfs niet multi-threaded, het is ook maar een hobby projectje waar ik zonder een design gewoon aan ben begonnen. Dus in principe zou ik best nog een singleton kunnen gebruiken. Aan de andere kant, zou ik misschien het best kunnen vermijden.. Want je weet maar nooit wat de toekomst gaat brengen natuurlijk..

[djengizz]

Bedenk ook dat Singletons zorgen voor tightly coupling and dat Singletons het testen van een applicatie moeilijker maakt (je kunt bijvoorbeeld geen mock object gebruiken).
Het wordt dan ook door velen als antipattern beschouwd.

[Robtimus]

Standeman schreef op Friday 02 September 2005 @ 13:47:
Nog even wat anders. Ik gebruik in mijn applicatie meerdere instanties van dezelfde ComboBox. Deze combox is een afgeleid van een normale combobox alleen worden er wat waarden ingelezen vanuit de DB en zijn er wat functies toegevoegd. Is het handig om hier een singleton van te maken.. Dan hoef ik ze namelijk niet apart te initialiseren indien er een waarde wijzigt. Of is het misschien handiger om ze een listener te geven welke voor een soort van reinitialiseEvent luisterd? (ik snap events nog niet voor 100%, dus dat laatste wordt wel een stuk lastiger).

Je kunt components niet zomaar aan meerdere containers toevoegen. Waar je eens naar moet kijken is de ComboBoxModel (en de implementatie DefaultComboBoxModel). Je maakt daar 1 instantie van en geeft die aan elke combobox mee in de constructor. Je kan dan gewoon alles doen met dat ene model en alle comboboxen worden aangepast qua inhoud. Let alleen wel op tijdens het verwijderen van items, eventueel geselecteerde waarden raken dan wel verloren als dat item verwijderd wordt.

[Verwijderd]

djengizz schreef op Friday 02 September 2005 @ 19:34:
Het singleton Pattern kent synchronisatie anders zou het nooit thread-safe zijn.

Dat is niet waar, hangt er maar net vanaf hoe je het implementeerd. Als je lazy load moet je inderdaad je methode synchroniseren, anders kun je gewoon statisch initialiseren.

[Standeman]

IceManX schreef op maandag 05 september 2005 @ 13:13:
[...]
Je kunt components niet zomaar aan meerdere containers toevoegen. Waar je eens naar moet kijken is de ComboBoxModel (en de implementatie DefaultComboBoxModel). Je maakt daar 1 instantie van en geeft die aan elke combobox mee in de constructor. Je kan dan gewoon alles doen met dat ene model en alle comboboxen worden aangepast qua inhoud. Let alleen wel op tijdens het verwijderen van items, eventueel geselecteerde waarden raken dan wel verloren als dat item verwijderd wordt.

Hey dat klinkt wel goed en lost denk ik een hoop van mijn problemen op

Maar dan heb ik wel 1 vraagje... Waar laat ik het model? Geeft ik het aan alle panels / forms mee waar toevallig die ene ComboBox wordt geinitialiseerd of stop ik hem in mijn ApplicationContext... (even het verwijder probleem negerend..)

Het meegeven aan al mijn panel en forms lijkt me geen goed plan.. niet alleen zal dat mij een hoop werk bezorgen op het moment.. in de toekomst zal ik er altijd rekening mee moeten houden... Dus ik denk dat ik 'm dan in mijn ApplicationContext object ga zetten....

Iemand die er tegen is?

[Robtimus]

Trouwens iets wat ik vergeten was: als je in 1 combobox een waarde selecteert, dan gebeurt dat in alle comboboxen met hetzelfde model (uitzondering: JTables).

Allemaal verschillende DefaultComboBoxModels gebruiken met dezelfde Vector in de constructor werkt niet, zodra je iets aan die Vector toevoegt dan verdwijnt vaak de inhoud uit de combobox. Misschien dat je zelf een afgeleide schrijven van AbstractListModel kunt schrijven die wel werkt. Kijk maar eens naar de implementatie van de DefaultComboBoxModel hoe die dat doen.