Architectuur van treeviews

[Verwijderd]

Ik was eigenlijk benieuwd of er bekende architecturen zijn om generieke treeviews te onderhouden. Een voorbeeld hiervan is de windows explorer, er kan van alles aan worden toegevoegd, folders, files, webdav connecties, netwerk connecties, en ik kan me daarom goed voorstellen dat er niet een enkel object is wat de treeview samenstelt maar dat elk afzonderlijk object zijn eigen gedeelte treeview onderhoud. Ik zit nu zelf met een soortgelijke aanpak vast, ik ben aanbeland op een punt waar een enkel stuk business logic de treeview opbouwt. Als je nu het geheel aanvulbaar wilt houden moet je continue in de business logic gaan klooien,

if selectedNode.type == doe dit menu
if selectedNode.type == doe dat menu
if , if, if..

Daar moet toch iets generieks voor bestaan? Als ik in de toekomst bijvoorbeeld andere node typen wil gaan toevoegen, wil ik niet de achterliggende treeview code weer gaan aanpassen om dat nieuwe type te kunnen begrijpen.

[Alarmnummer]

Zoek eens op Inversion Of Control.

[Verwijderd]

Kijk is aan, ik vroeg me al af of mijn probleemstelling duidelijk genoeg was

[Alarmnummer]

Verwijderd schreef op zaterdag 11 december 2004 @ 21:12:
Kijk is aan, ik vroeg me al af of mijn probleemstelling duidelijk genoeg was

Als jouw boomstructuur maar met generieke tree nodes kan werken (dus niet hoeft te weten hoe de binnenkant eruit ziet) kan je natuurlijk verschillende soorten nodes gebruiken. Zo lang ze zich maar houden aan dat algemene contract.

Eventueel kan je aan de nodes bij het uitvoeren van een commando ook de omgeving meegeven zodat je in je treenode natuurlijk heel veel specifieke dingen kunt doen aangezien je nu overal bij kunt komen.

[ Voor 20% gewijzigd door Alarmnummer op 11-12-2004 21:16 ]

[Verwijderd]

Ik heb net een stuk van martinfowler bekeken, en vooralsnog lijkt het veel op het observer pattern. Mijn treeview kan in principe alles bevatten (http://www.mschopman.demon.nl/treeview_v1.5/treeview.html) ik zit alleen zwaar te kloten met de achterliggende code. Ik heb nu een treeview gevuld met pagina objecten, nu hang ik er een task object in en dat task object moet zijn eigen business logic hebben, niet een generieke business logic. Het is nogal abstract om uit te leggen ook.

[Alarmnummer]

Verwijderd schreef op zaterdag 11 december 2004 @ 21:25:
Ik heb net een stuk van martinfowler bekeken, en vooralsnog lijkt het veel op het observer pattern. Mijn treeview kan in principe alles bevatten (http://www.mschopman.demon.nl/treeview_v1.5/treeview.html) ik zit alleen zwaar te kloten met de achterliggende code. Ik heb nu een treeview gevuld met pagina objecten, nu hang ik er een task object in en dat task object moet zijn eigen business logic hebben, niet een generieke business logic. Het is nogal abstract om uit te leggen ook.

De boom die hoeft toch alleen een bepaalde node te 'activeren', zeggen van 'doe je taak'. Het zal die boom een worst zijn wat die doet:

code:

interface TaskNode{
    void execute();
}

class PrrrrTaskNode implements TaskNode{
    void execute(){
        System.out.println("prrrrr");
    }
}

class OntplofTaskNode implements TaskNode{
     void execute(){ 
          System.out.println("Boem");
     }
}


//en hier een schets wat in de boom staat:
void treeListener(TaskNode selectedNode){
     selectedNode.execute();
}

Het zal die boom worst zijn wat die node doet.. en hoe die actie is geimplementeerd. Zo lang de boom maar weet dat de node zich aan zijn contract (in dit geval een interface) houd.

Je kunt trouwens in die execute methode dus allerlei dingen gaan doen.. dus ook calls naar jouw domain laag en logica. (Dus geen domain logica in de nodes zelf)

[ Voor 21% gewijzigd door Alarmnummer op 11-12-2004 21:57 ]

[odysseus]

Aangezien alle nodes waarschijnlijk veel code delen (zichzelf updaten, aantal onderliggende nodes uitzoeken, zichzelf tonen/verbergen, etc.) zou je er ook voor kunnen kiezen om in plaats van de interface van Alarmnummer een basisklasse te gebruiken waarin je standaardgedrag programmeert en dan vervolgens in alle specifiekere nodes overschreven methodes te gebruiken. Eventueel kan je de twee oplossingen ook nog combineren. Iets als het volgende dus:

Java:

interface TaskNode{
    void execute();
}

public class StandardTaskNode implements TaskNode
{
    public void execute()
    {
        //voer een standaard execute uit
    }

    public void add(TaskNode tn)
    {
        //voeg op standaardmanier een nieuwe node toe
    }

    public void show()
    {
        //toon deze node
    }
}

public class SpecializedTaskNode extends StandardTaskNode
{
    public void show()
    {
        //toon niet alleen dit element, maar ook alle onderliggende
    }
}

In dit voorbeeld hoef je immers niet elke keer opnieuw de code toe te voegen om nodes toe te voegen - op eenzelfde manier kan je natuurlijk alle andere gemeenschappelijke activiteiten in die class plaatsen.

Overigens is bovenstaande aanpak natuurlijk niet direct te gebruiken als nodes ook van een ander object moeten extenden - in dat geval zou je een tree met algemene 'domme' nodes kunnen gebruiken die een instantievariabele hebben waarin de 'echte' node zit en waaraan ze alle opdrachten doorgeven. Het is echter de vraag of de oplossing van Alarmnummer niet mooier is in zo'n situatie .

[alienfruit]

Wat is mis met het Command-pattern

[Alarmnummer]

alienfruit schreef op zondag 12 december 2004 @ 18:29:
Wat is mis met het Command-pattern

Uhhh... geef wel ff een onderbouwde reply ipv wat kreten rond te schreeuwen.

[alienfruit]

Ik ga er vanuit dat men de standaard design patterns wel kent hier <g>

Command Design Pattern

[Xu]

alienfruit schreef op zondag 12 december 2004 @ 19:35:
Ik ga er vanuit dat men de standaard design patterns wel kent hier <g>

Command Design Pattern

Volgens mij doelt 'Alarmnummer' meer wat je met het kreet 'Command Pattern' mee wilt doen in deze situatie.(misschien wat pseudo codes laten zien als voorbeeld).

Misschien begrijp ik wel wat je ermee bedoelt, dat je per node de executie wordt opgevangen aan de hand van een command pattern.?