[gui4gl-devel] Re: Aanpassingen van gisteren teruggedraaid

  • From: "Frank van Puffelen" <Frank.vanPuffelen@xxxxxxxxxxxxxx>
  • To: <gui4gl-devel@xxxxxxxxxxxxx>
  • Date: Mon, 15 Dec 2003 15:06:59 +0100

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: