Ehm, ik heb niet zo veel tijd, maar goed, wie a zegt moet b zeggen.
Ik zat in mijn hoofd met zoiets.
Je hebt het Decorator pattern, dus je kunt @runtime bijvoorbeeld een scherm (of dialog) decoreren met allemaal toeters en bellen. Plus je voorkomt een combinational explosion.
Hoe?
http://www.exciton.cs.ric...erns/DecoratorPattern.htm
Zie plaatje.
AComponent is dan een abstracte Dialog klasse of interface.
ConcreteComponent is een subklasse ervan en stelt je (lege) Dialog voor.
Decorator lijkt me duidelijk
ConcreteDecoratorA, B, C t/m ... zijn Decorators die iets toevoegen aan je Dialog, bijvoorbeeld een Ok knop, Dropdown o.i.d.
Blijft doStuff Over.
In je Dialog is dat dan de code die a) de Dialog maakt of b) de Dialog rendert.
Dat zou ik in je Decorators implementeren als een methode die a) een component toevoegt aan je Dialog of b) echt iets rendert.
Je maakt je dialog dan uiteindelijk aan met zoiets:
Java:
1
2
3
4
5
6
7
| Dialog myDialog = new DropDownDecorator(
new ComboDecorator(
new OkOrCancelButtonGroupDecorator(
new Dialog()
)
)
); |
Blijven op het eerste gezicht twee issues over.
a) Het mooi renderen van je Dialog als je gekke combi's wil. In Java kun je er een LayoutManager voor definieren, voor Win32 weet ik het even niet.
b) Een nette afhandeling van events. Zou je eventueel in de Decorators zelf kunnen coderen of ervan afwijken door ze te subklassen. Of iets zoals in Swing met ActionListeners.
Dus zoiets:
Java:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| class Client implements DialogEventListener, OkOrCancelButtonGroupListener, ComboListener {
private void createDlg() {
Dialog myDialog = new Dialog();
myDialog.addDialogEventListener(this);
Decorator okCancel = new OkOrCancelButtonGroupDecorator(myDialog);
okCancel.addOkOrCancelButtonGroupListener(this);
Decorator combo = new ComboDecorator(okCancel);
combo.addComboListener(this);
}
public void processDialogEvent(Event e) {
// doe iets met die e
}
// Overige listener methoden, plus de rest van de klasse
} |
Ik heb dit maar even snel ingeklopt, dus er kunnen wel wat kromme dingen in staan.
:strip_icc():strip_exif()/u/43400/avatar.jpeg?f=community){kind=avatar}
), checkboxCols (aantal "kolommen" van checkboxes, stel dat het er meer dan 5 zijn bijv), maxCheckboxWidth (max. breedte van een checkbox + bijbehorend label) enzovoorts enzovoorts. En ook qua methods is dat niet anders.
/u/147737/foto.png?f=community)
Bye-bye maintainability, re-usability etc :strip_exif()/u/69343/unrealtuxsquare5si.gif?f=community)
:strip_icc():strip_exif()/u/36003/crop584e9e5c223bd.jpeg?f=community)
:strip_icc():strip_exif()/u/84176/crop577a4401d15ce_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/6754/image.jpg?f=community)
/u/113601/crop5e3f183d640f8_cropped.png?f=community)
Maar zoals je in mijn TS kunt zien zijn er niet altijd geschikte kant-en-klaar dialogen...:strip_icc():strip_exif()/u/10274/crop67712295188a6_cropped.jpg?f=community)
Als je 9 van de 10 keer er wel gebruik van kunt maken lijkt me dat al voldoende...