[gui4gl-devel] Re: Aanpassingen van gisteren teruggedraaid

  • From: "Tako Schotanus" <quintesse@xxxxxxxxxxxxxxxxxxx>
  • To: <gui4gl-devel@xxxxxxxxxxxxx>
  • Date: Mon, 15 Dec 2003 15:09:58 +0100

Blijft het probleem bestaan dat als jouw Container nog niet is gemaakt
er ook niemand is om jouw properties door te geven.

Dat was ook de reden waarom ik gisteren de properties gewoon helemaal
uit de constructor had gehaald zodat je een "delayed initialization" kon
doen, maar daar haal je je meteen een hele hoop andere problemen op de
hals.

-Tako

> -----Original Message-----
> From: gui4gl-devel-bounce@xxxxxxxxxxxxx 
> [mailto:gui4gl-devel-bounce@xxxxxxxxxxxxx] On Behalf Of Frank 
> van Puffelen
> Sent: maandag 15 december 2003 15:07
> To: gui4gl-devel@xxxxxxxxxxxxx
> Subject: [gui4gl-devel] Re: Aanpassingen van gisteren teruggedraaid
> 
> 
> Waarom niet gewoon de context er door de container uit laten 
> slopen? Dus
> de Window geeft niet de originele theme/properties door aan de Button,
> maar eentje waar z'n eigen "naam" vanaf gesloopt is. Verschil met de
> optie 1 die jij voorstelt is dat de button hier dus niks meer hoeft te
> weten van het window (de container).
> 
>       puf
> 
> 
> -----Original Message-----
> From: Quintesse 
> Sent: maandag 15 december 2003 14:42
> To: gui4gl-devel@xxxxxxxxxxxxx
> Subject: [gui4gl-devel] Re: Aanpassingen van gisteren teruggedraaid
> 
> 
> 
> Precies, dat komt dus overeen met optie #1 die ik beschreef en komt er
> dus op neer dat Widgets in hun constructor al moeten weten wie hun
> parent (container) is. Voor een CompoundWidget kun je dat 
> eventueel nog
> wel vereisen (widget ontwikkelaars horen de ins en outs beter te
> begrijpen), maar een gebuiker wil misschien gewoon dit kunnen doen:
> 
> Button b = new Button();
> Window w = new Window();
> w.add(b);
> 
> Zeker aangezien dit heel normaal is bij AWT en Swing.
> 
> Met optie #1 zou dit worden:
> 
> Window w = new Window(...);
> Button b = new Button(w, "okButton");
> 
> en in het Theme zou je dus
> 
> okButton.backgroundColor = Color.RED
> 
> kunnen doen.
> 
> Met optie #2 gaat het zo:
> 
> Button b = new Button("okButton");
> Window w = new Window(...);
> w.add(b);
> 
> of andersom als je dat wilt:
> 
> Window w = new Window(...);
> Button b = new Button("okButton");
> w.add(b);
> 
> 
> Voordeel van optie #1 is dat een diepere hierarchie automatisch goed
> gaat terwijl je bij optie #2 in de constructor zoiets zal moeten doen
> als dit:
> 
> public Button(String _sName, String _sCaption) {
>    m_caption = new Text(sName + ".caption", _sCaption);
> }
> 
> Het gaat hierbij dus vooral om die ' sName + ".caption" '. 
> Ten eerste is
> het jammer dat je die naam er aan moet plakken want die vergeet je
> misschien te makkelijk en ten tweede zal het iets ingewikkelder moeten
> want _sName kan leeg zijn en dan moet die punt er niet voor staan. DUs
> moet er waarschijnlijk een helper method komen in de baseclass om
> property namen te concatteneren:
> 
> public Button(String _sName, String _sCaption) {
>    m_caption = new Text(buildName(sName, "caption"), _sCaption);
> }
> 
> Al met al zal dat geen schoonheidsprijzen winnen.
> 
> -Tako
>  
>  
> > -----Original Message-----
> > From: gui4gl-devel-bounce@xxxxxxxxxxxxx 
> > [mailto:gui4gl-devel-bounce@xxxxxxxxxxxxx] On Behalf Of Frank 
> > van Puffelen
> > Sent: maandag 15 december 2003 14:19
> > To: gui4gl-devel@xxxxxxxxxxxxx
> > Subject: [gui4gl-devel] Re: Aanpassingen van gisteren teruggedraaid
> > 
> > 
> > Als je de properties inderaad opslaat zoals ik hieronder beschrijf
> > (SaveDialog.TopPanel.ProgressBar.BackgroundColor=clBlack), 
> > zou eventueel
> > elke containercomponent zelf al zijn prefix van de propertynames af
> > kunnen slopen. Op die manier zien de contained componenten 
> niet dat ze
> > onderdeel van een groter geheel zijn en hoef je dus ook geen 
> > prefix mee
> > te geven in de constructor.
> > 
> >     puf
> > 
> > 
> > -----Original Message-----
> > From: Quintesse 
> > Sent: maandag 15 december 2003 14:03
> > To: gui4gl-devel@xxxxxxxxxxxxx
> > Subject: [gui4gl-devel] Re: Aanpassingen van gisteren teruggedraaid
> > 
> > 
> > 
> > Nou die loadProperties() is nu precies wat er weer uit 
> gehaald is ;-)
> > 
> > Wat er gebeurt is dat de (default) properties voor een Widget in de
> > constructor uit he huidige actieve Theme worden opgehaald. 
> Dat gebeurt
> > in de constructor zodat je dit soort dingen kunt doen:
> > 
> > Button button = new Button();
> > button.setBackgroundColor(Color.RED);
> > window.add(b);
> > 
> > De default is dan al gespecificeerd door de constructor en de 
> > gebruiker
> > override 'm met z'n eigen waarde in de regel direct erna.
> > 
> > Tot voor kort waren de properties niet hierarchisch en kon er was de
> > combinatie (classname, propertyname) voldoende om een 
> > property uniek te
> > identificeren. Maar met een hierarchisch systeem moet je nu in de
> > constructor dus al weten welke property er opgehaald moet worden. Je
> > moet dus de combinatie (classname, path, propertyname) weten 
> > voordat je
> > de property uniek kunt identificeren. De manier waarop de properties
> > worden opgeslagen in het Theme maakt daarbij niets uit (niet in een
> > Theme dat globaal en niet context gevoelig is iig).
> > 
> > Een andere oplossing zou zijn dat je properties pas gaat 
> > "resolven" als
> > ze worden opgevraagd, maar dat zou het property systeem in 
> de widgets
> > lastiger maken (waardoor het maken van widgets ook lastiger wordt
> > waardoor mensen minder snel nieuwe widgets gaan maken ben ik bang).
> > 
> > -Tako
> > 
> > -----Original Message-----
> > From: gui4gl-devel-bounce@xxxxxxxxxxxxx
> > [mailto:gui4gl-devel-bounce@xxxxxxxxxxxxx] On Behalf Of Frank van
> > Puffelen
> > Sent: maandag 15 december 2003 13:38
> > To: gui4gl-devel@xxxxxxxxxxxxx
> > Subject: [gui4gl-devel] Re: Aanpassingen van gisteren teruggedraaid
> > 
> > 
> > Aha, ik begrijp 't net van Steven. De properties staan in 
> een file als
> > lijst. En die lijst bevat de FQN. Dus iets als:
> >    SaveDialog.TopPanel.ProgressBar.BackgroundColor=clBlack
> >    SaveDialog.TopPanel.BackgroundColor=clWhite
> > 
> > Als je dat zo wilt houden (je kunt ook de properties hierarchisch
> > opslaan), dan is het volgens mij het meest voor de hand 
> liggend om een
> > aparte loadProperties-operatie te maken. Deze kun je dan 
> dus aanroepen
> > na het construeren van de hierarchie.
> > 
> > Of heb ik 't mis en heb je de properties juist nodig om de 
> > hierarchie te
> > maken?
> > 
> >     puf
> > -----Original Message-----
> > From: Frank van Puffelen 
> > Sent: maandag 15 december 2003 13:29
> > To: gui4gl-devel@xxxxxxxxxxxxx
> > Subject: [gui4gl-devel] Re: Aanpassingen van gisteren teruggedraaid
> > 
> > 
> > Waarom moet je tijdens de constructie de FQN al weten?
> > -----Original Message-----
> > From: Quintesse 
> > Sent: maandag 15 december 2003 13:22
> > To: gui4gl-devel@xxxxxxxxxxxxx
> > Subject: [gui4gl-devel] Aanpassingen van gisteren teruggedraaid
> > 
> > 
> > Ok, de aanpassingen gisteren waarbij de initialisatie van theme
> > proeprties in widgets uit de constructor werd gehaald is weer
> > teruggedraaid want het werd gewoon een zooitje.
> > 
> > De naam van een Widget kan nu aan de constructor worden 
> doorgegeven en
> > is niet te veranderen.
> > 
> > Het probleem waar ik nu mee zit is dat de naam niet het 
> > volledide pad is
> > en dat om het volledige pad te weten te komen er een method is
> > getFullName() die recursief de hierarchie omhoog loopt om 
> > alle namen aan
> > elkaar te plakken (met punten ertussen). Maar op het moment dat een
> > Widget wordt gemaakt zit ie nog niet in de hierarchie.
> > 
> > Ik zie hiervoor 2 oplossingen:
> > 
> > 1. geef aan alle constructors naast de naam ook de parent door. Dit
> > heeft als nadeel dat er dus een impliciete "parent.add(this)" 
> > gedaan zal
> > moeten worden in de constructor.
> > 
> > 2. geef als naam al een FQN (Fully Qualified Name) door. Om die te
> > krijgen zal een CompoundWidget dus z'n eigen FQN voor die van z'n
> > sub-widgets moeten plakken en heeft als nadeel dat je dan niet meer
> > makkelijk iets kunt doen als 
> > CompoundWidget.getChildByName("valueLabel")
> > 
> > Ik neig zo langzamerhand naar optie 2 omdat ik die 
> impliciete add echt
> > niet fijn vind, maar je eigen hierarchie moeten opgeven in de 
> > naamgeving
> > terwijl die af te leiden is uit de widget hierarchie vind ik 
> > wel jammer.
> > 
> > Nog enig commentaar voordat ik toch maar optie 2 doe?
> > 
> > -Tako
> > 
> > 
> 
> 
> 
> BackStream(R)
> Willem de Zwijgerlaan 350-352
> 1055 RD Amsterdam
> The Netherlands
> tel. +31 20 386 8365
> fax +31 20 386 8948 
> 
> Post Office Address: 
> Postbus 58385
> 1040 HJ Amsterdam
> 
> BackStream: The Digital Delivery Company
> www.backstream.com
> 
> This e-mail and any attachment may contain confidential and 
> privileged material intended for the addressee only. If you 
> are not the addressee, you are notified that no part of the 
> e-mail or any attachment may be disclosed, copied or 
> distributed, and that any other action related to this e-mail 
> or attachment is strictly prohibited, and may be unlawful. If 
> you have received this e-mail by error, please notify the 
> sender immediately by return e-mail, and delete this message. 
> BackStream, its subsidiaries and/or its employees shall not 
> be liable for the incorrect or incomplete transmission of 
> this e-mail or any attachments, nor responsible for any delay 
> in receipt.
> 
> 


Other related posts: