[php] trees mooi opbouwen

[Verwijderd]

Een bekende is bezig met het maken van een tree lister (zoiets als de verkenner) maar dan voor een CMS nu zit hij met het volgende probleem



met de volgende code

PHP:

function getLevels ($id, $level = 0) {   
    global $table_prefix;
    global $absolute_url_page;
    global $strings;

    $level2=$level;
    $level++;

    $sql = "SELECT * FROM " . $table_prefix . "content WHERE child = $id ORDER BY menu_order";
    $query = mysql_query($sql);   

    if (mysql_num_rows($query) > 0) {   
        

        $level2 = $level +1;
        for ($x = 0; $x < mysql_num_rows($query); $x++) {   
            $list = mysql_fetch_object($query);   

            $but = $list->id; 
            $lijnicon = 'lijn.gif';
            $errorid = $id ; $errorlevel = $level;
            $x2 = mysql_num_rows($query) -1;
            if ((mysql_num_rows($query)) == ($x + 1)) { $hoekicon = "hoekonder.gif"; } else { $hoekicon = "hoek.gif";  }
                echo '   <tr> <td>';
                    
                echo str_repeat("[img]\"../images/tree/"[/img]",$level) ;
                echo "[img]\"../images/tree/".[/img]" . $id .
                          '<a href="edit.php?edit_id=' . $list->id . '">' . 
                          "[img]\"../images/tree/page.gif\"[/img]" .
                          $list->title . "<font color =\"#A0A0A0\"> (" .  $list->id . ")</font>". '</td> 

                      <td width="20"><a href="' . $absolute_url_page . '/?n=' . $list->id . '" target="_blank">' .  '[img]"../images/tree/preview.gif"[/img]</a>' .'</td>
                      <td width="20">[img]"../images/tree/oog'[/img]enabled . '.gif">' .'</td>
                      <td width="20"><font color="#A0A0A0">' . $level2. '.' . $list->menu_order.'</font></td> 
                 </tr>'; 
           getLevels($list->id, $level);   
        } 
    }

nu wil hij eingelijk weten hoe hij die | images die doorgaan goed kan verwerken, heeft iemand tips voor deze man! zodat hij zijn tree mooi kan maken?

^{mij lukte het nie}

[plakbandrol]

hmm ik ben dus die man (zie dit topic nu pas)

maargoed iemand een idee?

de code is trouwens nog wel een puinhoop aangezien ik midden in het debug proces zat toen ik de code naar xtentic stuurde dus let daar niet op

[ Voor 64% gewijzigd door plakbandrol op 26-02-2003 20:49 ]

[Verwijderd]

Ik heb het zelf zo opgelost: (dat was een stuk groter, weet niet of het zo klein ook werkt)


1: achtergrond plaatje ter breedte van de cel met in het midden een streepje (bij mij een streepje en stukje blank vanwege stippellijn als in explorer) wat dus herhaald over de hoogte van de cel.
2: plaatje ter breedte van de cel met alleen aan de rechter helft een streepje. Midden in de cel uitlijnen (verticaal gezien natuurlijk)

[edit]
ik zie intussen dat dit het probleem niet echt is...

[ Voor 7% gewijzigd door Verwijderd op 26-02-2003 21:00 ]

[ACM]

Wat is nou precies het probleem?

Dat plaatje dat je nu toont is hoe het nu is? En je wilt t-splitsingen hebben, ipv zo'n lelijk stukje wit?
Ik denk dat je zoiets moet doen:
if(has_children($node))
print(t_splitsing);
else
print(corner);

Volgens mij gaat het dan redelijk goed, hoe dat vertaald naar jullie code ga ik niet uitzoeken
Wellicht kan je het best de boom eerst in het geheugen zetten als je veel checks moet doen.

[plakbandrol]

die hoek is het probleem niet, het gaat erom dat hij die verticale lijn niet moet weergeven op het moment dat er geen submenu's meer zijn.. en das nogal lastig te verwerken in de code

[ Voor 3% gewijzigd door plakbandrol op 26-02-2003 21:02 ]

[plakbandrol]

kijk waar ik de rode lijn neer heb gezet moet geen lijn komen

[ Voor 56% gewijzigd door plakbandrol op 26-02-2003 21:05 ]

[ACM]

Kan je niet een array van de levels bijhouden?

En dan dus per level een boolean setten voor het wel/niet tonen van een lijntje, via je recursieve functie?
Zodra je weer level up gaat, die uit je array halen.

[ Voor 24% gewijzigd door ACM op 26-02-2003 21:05 ]

[plakbandrol]

ACM schreef op 26 February 2003 @ 21:05:
Kan je niet een array van de levels bijhouden?

En dan dus per level een boolean setten voor het wel/niet tonen van een lijntje?

das nou net het probleem, het is een combinatie van de sub catagorie en de level, want een paar items verder kan het zijn dat op dezelfde level wel een lijn moet komen

[Verwijderd]

plakbandrol schreef op 26 February 2003 @ 21:06:
[...]

das nou net het probleem, het is een combinatie van de sub catagorie en de level, want een paar items verder kan het zijn dat op dezelfde level wel een lijn moet komen

Kortom voordat er dingen geplaatst gaan worden moet er al een array oid gemaakt worden waarin bekend is hoe het zit met de rijen verderop.

In het andere topic wat op dit moment loopt staat een simpele uitleg hoe je een menu via een array kunt maken, met dat idee als basis en het bovenstaande moet er wel een en ander mogelijk zijn. Ben je ook gelijk van een hele rits overbodige queries af.

Nog een tip:
http://www.treeview.net/ - de 'menu tags' hiervoor kan je heel makkelijk vanuit een scriptje maken, het javascript doet de rest. Je hebt gelijk een mooi en werkend menu. Misschien ook het overwegen waard om jezelf veel moeite te besparen. En het werkt nog eens makkelijker ook als het menu groot wordt, want je kan delen dichtklappen etc.

[ Voor 21% gewijzigd door Verwijderd op 26-02-2003 21:14 ]

[plakbandrol]

Verwijderd schreef op 26 February 2003 @ 21:11:
[...]
Nog een tip:
http://www.treeview.net/ - de 'menu tags' hiervoor kan je heel makkelijk vanuit een scriptje maken, het javascript doet de rest. Je hebt gelijk een mooi en werkend menu. Misschien ook het overwegen waard om jezelf veel moeite te besparen. En het werkt nog eens makkelijker ook als het menu groot wordt, want je kan delen dichtklappen etc.

net toen ik die site aan het doorbrowsen was ging ie offline

-edit- ow hij doet het weer

maar ik denk dat ik die van www.treeview.com ga proberen te gebruiken, die is gratis

[ Voor 7% gewijzigd door plakbandrol op 26-02-2003 21:21 ]

[Verwijderd]

www.treeview.com doet het bij mij weer niet
maar www.treeview.net is ook gratis hoor, dus daar hoeft het niet van af te hangen

[plakbandrol]

die treeview.net is inderdaad een stuk beter, ff kijken of ik die aan de praat krijg icm php

[ACM]

plakbandrol schreef op 26 February 2003 @ 21:06:
das nou net het probleem, het is een combinatie van de sub catagorie en de level, want een paar items verder kan het zijn dat op dezelfde level wel een lijn moet komen

Ja, je zult alsnog moeten kijken of het level waar je _uit_ gaat (omdat je dieper gaat) nog andere children heeft dan de gene die getoond wordt, maar dat lijkt me geen moeilijke functie als je je tree al in een stuk php-code hebt.

[Genoil]

Ja het probleem van de T-stukjes, een mooi probleem is het

uit void SUB_Tree::recurse(SUB_Node &$cNode):

PHP:

..
$iDepth = $this->m_iDepth;
..
for($n = 0; $n < count($cNode->m_aChildren); $n++)
{
    $cChild = &$cNode->m_aChildren[$n];
                                                
    if($n == count($cNode->m_aChildren)-1)
    {
        $this->m_aImages['branch'] = "rel_cc.gif";
        $this->m_aIndent[$iDepth] = FALSE;
    }
    else
    {
        $this->m_aImages['branch'] = "rel_ct.gif";
        $this->m_aIndent[$iDepth]    = TRUE;            
    }       
    $this->recurse($cChild);
}

Hier zit em de kneep. Ff kort uitleggen wat SUB_Tree voor een ding is: Het is een Template object dat een boomstructuur van SUB_Nodes aangeleverd krijgt (waar alle data dus inzit). Z'n execute() method roept de recurse method aan met de root node, include het bijbehorende template en roept daarna de recurse functie aan voor al root z'n kinderen (enz).

Dat laatste stukje staat hierboven. Vlak voordat de recurse method wordt aangeroepen op de Child, check ik of het het het laatste kind (L stukje) is of ergens middenin (T stukje). Met die waarde voor de "branch" (T of L - stukje). Ook houdt ie een array (m_aIndent) bij waarin staat of ie een I stukje of een whitespace moet renderen in het gebied voor de branch+icon.

Let op dat dit dus 1 enkel object is dat een hele tree rendert, niet 1 object per node. Da's wel tamelijk cruciaal.

edit:

en denk ff goed na of je echt wat hebt aan zo'n javascript-tree. Als je je tree gebruikt in een CMS met veel nodes, kan dat betekenen dat je erg vaak je gehele tree moet refreshen. ik ben nu met een systeem bezig, waar naast het bewerken van de inhoud van de nodes, het bewerken van de boomstructuur tot de hoofdactiviteiten behoort. dan wil je niet elke keer de gehele tree binnensluizen. wat ik dus doe, is gewoon alle nodes in het huidge pad openklappen en daar een statische non-javascript html van bakken. gebruikvriendelijk zat, en het scheelt een hoop geklooi met javascript. het enige alternatief is zo'n vette tree als op msdn, die zonder refresh kleine stukjes boom kan inladen/verversen.

[ Voor 25% gewijzigd door Genoil op 26-02-2003 23:20 ]

[ACM]

Dat stuk code doet dus wat ik bedoel met een arraytje voor het bepalen of je wel/geen streepje moet neerplakken

[Genoil]

ACM schreef op 26 February 2003 @ 23:10:
Dat stuk code doet dus wat ik bedoel met een arraytje voor het bepalen of je wel/geen streepje moet neerplakken

hoofdbrekens heeft het me gekost, en zo simpel bleek de oplossing

[ACM]

Genoil schreef op 26 februari 2003 @ 23:21:
hoofdbrekens heeft het me gekost, en zo simpel bleek de oplossing

Vreselijk he? Dat je uren kan besteden aan iets, terwijl het best in twee minuten had gekund

* ACM heeft het ook veel te vaak.

[Genoil]

ACM schreef op 26 February 2003 @ 23:27:

[...]

Vreselijk he? Dat je uren kan besteden aan iets, terwijl het best in twee minuten had gekund

* ACM heeft het ook veel te vaak.

* Genoil leunt dan gewoon tevreden naar het scherm starend achterover en verspeelt daarmee nog meer tijd

Dit ziet er toch gewoon lekker uit nadat je eerst je tree wekenlang in courier-new hebt moeten aanschouwen:


[opschep]
dat oranje mapje? ja mijn tree is eigenlijk stiekem een "hypertree"
[/opschep]

[ACM]

Maar wel geinig

Kan ie ook nog meer niveau's aan? (aan natuurlijk wel, maar ook nog enigszins netjes weergeven) En zo ja, hoeveel queries heb je daar dan voor nodig? (of bijv voor bovenstaand screenietje)

[ Voor 18% gewijzigd door ACM op 27-02-2003 00:16 ]

[Genoil]

ACM schreef op 27 February 2003 @ 00:09:
Maar wel geinig

Kan ie ook nog meer niveau's aan? (aan natuurlijk wel, maar ook nog enigszins netjes weergeven) En zo ja, hoeveel queries heb je daar dan voor nodig? (of bijv voor bovenstaand screenietje)

Het het aantal niveau's diep is onbeperkt. Uiteraard geeft ie dat net zo netjes weer. Zoals ik al zei kan ie echter niet meerdere nodes op hetzelfde niveau openklappen. Dat zou ik wel kunnen maken, maar het kost queries en het is in de regel niet strikt noodzakelijk voor fijne navigatie.

Het aantal queries = diepte van je huidige node + 2. Die extra 2 zijn het zoeken naar de rootnode (afh. van user andere root, moet ik nog inbouwen maar da's het idee), en 1 voor het checken op gerelateerde nodes (die oranje in de screenie).

Met wat javascript zorg ik er ook nog voor dat de huidige node altijd in beeld komt (scrollbars goed zetten, het ding zit meestal in een frame).

Kep alleen nog wat problemen met sommige browsers. Ik kan het zo maken dat ie op macIE goed werkt, maar dan werkt ie op Mozilla niet meer (op winIE werkt ie hoe dan ook). In principe een kwestie van een net iets andere template gebruiken ('t is een DIV-positioning probleem), maar ik heb helemaal geen zin om een browser-template-selector te bouwen, er moet nog VEEEL meer gebeuren dat veel belangrijker is

Ultimate Goal [tm] is uiteindelijk zo'n MSDN style non-refreshing-dynamic-loading tree te bouwen, maar daar heb ik helemaal geen tijd voor.

[stekkel]

inderdaad een gave tree (wil ik ook ). Wat betreft die queries, kan je die niet gewoon cachen in de session zodat je uiteindelijk bij het uitklappen van een extra niveau slechts 1 query kwijt bent?

[Genoil]

stekkel schreef op 27 February 2003 @ 10:07:
inderdaad een gave tree (wil ik ook ). Wat betreft die queries, kan je die niet gewoon cachen in de session zodat je uiteindelijk bij het uitklappen van een extra niveau slechts 1 query kwijt bent?

+1 inspirerend

[Verwijderd]

Ik wil toch nogmaals wijzen op treeview.net:
- je kan het er net zo mooi uit laten zien als bovenstaande plaatje, door het vervangen van wat gifjes
- je kan meerdere nodes open hebben
- geen reload voor het openklappen
- het opbouwen gebeurd client-side, uitleg:

Als je een tabel hebt bv met id, parent_id, naam dan is het enige wat je moet doen alle records ophalen, en een regel printen voor de aanroep van het script met als parameters de naam van de node, de parent en de te tonen naam. Laat dat nou precies zijn wat in zo'n simpele tabel staat

[Genoil]

Verwijderd schreef op 27 February 2003 @ 13:10:
Ik wil toch nogmaals wijzen op treeview.net:
- je kan het er net zo mooi uit laten zien als bovenstaande plaatje, door het vervangen van wat gifjes
- je kan meerdere nodes open hebben
- geen reload voor het openklappen
- het opbouwen gebeurd client-side, uitleg:

Als je een tabel hebt bv met id, parent_id, naam dan is het enige wat je moet doen alle records ophalen, en een regel printen voor de aanroep van het script met als parameters de naam van de node, de parent en de te tonen naam. Laat dat nou precies zijn wat in zo'n simpele tabel staat

Ik ben het helemaal met je eens wat de pracht van treeview.net betreft. Een groot nadeel is alleen dat wanneer je bijvoorbeeld de naam van 1 node in de tree verandert, of, wat ingrijpender, een selectie van x nodes verplaatst naar een andere parent, je toch weer de gehele tree moet binnentrekken.

[Verwijderd]

wat bedoel je precies? Wat ik er zo van begrijp heb je het over opnieuw downloaden, maar dat verschil gaat ook op voor een 'platte' tree, en daarbij is het per item 40 tekens ofzo

Of bedoel je iets anders?

[SchizoDuckie]

Heej toevallig Ik moet zoiets ook vandeweek nog schrijven voor mijn cms.

Wat ik denk ik ga doen is een SELECT * FROM ROOTNODES en een SELECT * FROM CHILDNODES

Daar gooi ik een functie overheen die de complete tabel structuur naar een array pompt, en en die array sla ik op voor verder gebruik

Dan hoef je de volgende keren als er géén documenten bij gekomen of gewijzigd zijn (handig bijv. voor een sitemap) alleen maar die array in te laden, en daar een functie overheen te halen die de html structuur genereert.

Wordt er dan een document toegevoegd of gewijzigd, dan wordt automatisch ook de table structuur even ge-update

Comments?

[Bosmonster]

Papa Eend schreef op 27 februari 2003 @ 13:56:
[...]

Comments?

Ja.. Waarom in hemelsnaam 2 losse tabellen voor root en childnodes

Als je menu oneindig diep kan zijn dan kunnen childnodes dus ook weer childnodes als parent hebben.. Waarom dan niet ook gewoon je rootnodes in dezelfde tabel, want er zit dus geen verschil tussen root- en childnodes, behalve dat bijvoorbeeld rootnodes parent 0 hebben oid.

[ Voor 42% gewijzigd door Bosmonster op 27-02-2003 14:10 ]

[ACM]

sterker nog, een childnode van een rootnode is weer de rootnode van de subtree's onder die rootnode

[Genoil]

Verwijderd schreef op 27 februari 2003 @ 13:44:
wat bedoel je precies? Wat ik er zo van begrijp heb je het over opnieuw downloaden, maar dat verschil gaat ook op voor een 'platte' tree, en daarbij is het per item 40 tekens ofzo

Of bedoel je iets anders?

Nee dat bedoel ik idd . Ik zeg ook niet dat een 'platte' tree efficienter is wanneer je per refresh de gehele tree zou binnentrekken. Ik maak juist een 'offer' door slechts de nodes in m'n pad open te klappen, anders zou het echt veel te lomp worden. Het nadeel van de Javascript tree is daarentegen, dat ALS je hem moet downloaden, je gelijk ook de hele tree moet downloaden. En er is meer: Stel nou dat je de JS-tree gebruikt voor een groot CMS met veel users die tegelijkertijd de boomstructuur kunnen bewerken. Dan heb je mooi een probleem, omdat je bij elke actie alsnog moet gaan checken of er misschien niet iets in de huidige boom veranderd is door een andere user.

Met een 'serverside' tree zijn dit soort problemen imho veel eenvoudiger te ondervangen. Mijn tree gaat in eerste instantie op een intranet gebruikt worden en draait op een dedicated applicatieserver, dus echt lang wachten op je refresh is niet zo'n big deal. Voor een read-only frontend is zo'n treeview.net ding zeker een goede oplossing, zeker wanneer de tree niet zo vaak verandert van structuur en inhoud.

[Bosmonster]

ACM schreef op 27 februari 2003 @ 14:39:
sterker nog, een childnode van een rootnode is weer de rootnode van de subtree's onder die rootnode

sterker nog, dat zei ik gewoon

[plakbandrol]

Mij is het in ieder geval gelukt mbv die javascript tree

ziet er mooi uit, en het grote voordeel vind ik ook dat je kan in/uitklappen waardoor je dus alleen de hoofdpagina's ziet en niet alle nodes

aangezien die CMS bedoeld is voor mensen met 0,0 verstand van html e.d moet het makkelijk en overzichtelijk zijn, en daarom lijkt me dit de beste oplossing, ook omdat de meeste wel vertrouwd zijn met het principe van windows verkenner

-edit- ff screenie erbij

[ Voor 13% gewijzigd door plakbandrol op 27-02-2003 16:00 ]

[Verwijderd]

Nee dat bedoel ik idd . Ik zeg ook niet dat een 'platte' tree efficienter is wanneer je per refresh de gehele tree zou binnentrekken. Ik maak juist een 'offer' door slechts de nodes in m'n pad open te klappen, anders zou het echt veel te lomp worden. Het nadeel van de Javascript tree is daarentegen, dat ALS je hem moet downloaden, je gelijk ook de hele tree moet downloaden.

Het voordeel in dat geval is, dat de hele tree 9 van de 10 gevallen (bij mij iig) kleiner is dan een andere tree deels, omdat je daarbij met allemaal onnodige layout zut zit.
Dit argument gaat pas op als een ingeklapte node heeeel veel andere nodes bespaart, in de meeste geval niet

En er is meer: Stel nou dat je de JS-tree gebruikt voor een groot CMS met veel users die tegelijkertijd de boomstructuur kunnen bewerken. Dan heb je mooi een probleem, omdat je bij elke actie alsnog moet gaan checken of er misschien niet iets in de huidige boom veranderd is door een andere user.

en dat hoeft bij jou versie niet? dan lopen andere nodes die niet open staan achter op de werkelijkheid.

Met een 'serverside' tree zijn dit soort problemen imho veel eenvoudiger te ondervangen. Mijn tree gaat in eerste instantie op een intranet gebruikt worden en draait op een dedicated applicatieserver, dus echt lang wachten op je refresh is niet zo'n big deal. Voor een read-only frontend is zo'n treeview.net ding zeker een goede oplossing, zeker wanneer de tree niet zo vaak verandert van structuur en inhoud.

Wat ik wel een mooie methode vind is om bij iedere actie die invloed heeft op het menu een .js filetje te bakken wat op iedere pagina geinclude wordt. Is effecient voor server en bandbreedte.

Maargoed het blijft een persoonlijke keuze.

[plakbandrol]

je kan natuurlijk ook de tree laten auto-refreshen elke 20 sec oid, maar als meerdere mensen aan zo'n tree werken blijf je het probleem houden

[Genoil]

Verwijderd schreef op 27 februari 2003 @ 15:55:
en dat hoeft bij jou versie niet? dan lopen andere nodes die niet open staan achter op de werkelijkheid.

Mijn versie checkt sowieso bij elke navigatie de database om (het openstaande deel van) de tree eruit te halen, dus alle veranderingen worden automatisch meegenomen.

Wat ik wel een mooie methode vind is om bij iedere actie die invloed heeft op het menu een .js filetje te bakken wat op iedere pagina geinclude wordt. Is effecient voor server en bandbreedte.

Je bedoelt dat ie alleen de veranderingen doorgeeft die er gedaan zijn/ die nodes ophaalt die nodig zijn? Jah da's mooi .

[Genoil]

plakbandrol schreef op 27 February 2003 @ 16:02:
je kan natuurlijk ook de tree laten auto-refreshen elke 20 sec oid, maar als meerdere mensen aan zo'n tree werken blijf je het probleem houden

Ja ik moet idd nog wel even goed nadenken hoe ik ga voorkomen dat twee users bijvoorbeeld tegelijkertijd dezelfde node gaan editten. Kan er wel een soort 'lock' opzetten wanneer iemand in edit modus naar een node navigeert, maar ik weet niet hoe ik die lock er weer afhaal als de gebruiker stopt met werken en niet netjes uitlogged. Maar da;s een beetje offtopic, tzt open ik wel een topic over...

[stekkel]

ik weet niet wat voor database je gebruikt maar wanneer je automatisch een last modified veld laat updaten dan kan je je tree up to date houden door in je SQL query op te nemen:
where last_modified > tree-render-date.

Wanneer ik ff zit te denken hoe je het hele zaakje kan verversen .....
Je hebt de nodes die uitgeklapt zijn,
de childs van die node krijg je door where parent_node = some_id
wanneer je nu alles in een query wilt stoppen dan krijg je gewoon een leuke where definition met heel veel : or parent_node = xx or parent_node = xxx etc etc
De data die je terug krijgt is wel weer te gebruiken om je tree te initialiseren.

Wat locken betreft, wanneer je een record wilt updaten dan gebruik je gewoon
where field1 = oldvalue_field1 and field2 = oldvalue_field2 ....

Vervolgens check je of de update succesvol was en zo nee dan reporteer je dat aan je gebruiker, eventueel met de ververste data.

Ga je de tree source ooit nog opensource maken?

[Verwijderd]

Persoonlijk vind ik die javascript niets en zou het mooier vinden als plakbandrol um zelf zou maken

[Verwijderd]

Hehe. Waarom tree view gebruiken ?
Enig goede reden waarom je een tree view zal willen gebruiken in je cms?
Ik maak zelf gebruik van een flowchart/org. chart. ; leek mij wat duidelijker

[Verwijderd]

Verwijderd schreef op 28 February 2003 @ 23:41:
Hehe. Waarom tree view gebruiken ?
Enig goede reden waarom je een tree view zal willen gebruiken in je cms?
Ik maak zelf gebruik van een flowchart/org. chart. ; leek mij wat duidelijker

wat houd dat precies in?

Ik heb eerst ook overwogen een Tree te gebruiken.. later toch maar niet gedaan omdat het eigenlijk helemaal geen verschil had..

[Verwijderd]

Gewoon een flowchart; zoiets als:
http://www.devexpress.com/products/vcl/product.asp?ProdID=13

[Verwijderd]

Verwijderd schreef op 01 March 2003 @ 11:07:
Gewoon een flowchart; zoiets als:
http://www.devexpress.com/products/vcl/product.asp?ProdID=13

ooooooww.. dat... ... nee maar dat lijkt me dus niet duidelijk.. dat kost toch ontzettend veel ruimte (pixels op de pagina)

[Verwijderd]

Tja