[gui4gl-devel] Re: Aanpassingen van gisteren teruggedraaid
- From: "Frank van Puffelen" <Frank.vanPuffelen@xxxxxxxxxxxxxx>
- To: <gui4gl-devel@xxxxxxxxxxxxx>
- Date: Mon, 15 Dec 2003 14:19:12 +0100
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.
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.
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:
