In mijn CMS'je maak ik gebruik van een standaard parent-child tabel om de navigatie in op te slaan:
Ik ben nu bezig om de gebruiker een optie te geven pagina's kris-kras door de boom te verplaatsen:

Zie hier alleen het probleem: als iemand "Zomer" rechtstreeks onder "Home" wil zetten, is dat geen probleem. Ik verander dan de parent van "Zomer" van 2 (Groenten) naar 1 (Home). Maar het gaat fout als iemand "Groenten" onder een kind van "Groenten" wil zetten, zoals onder "Zomer". De nieuwe parent van "Groenten" wordt dan 6 ("Zomer"). De parent van "Winter" en "Zomer" blijft echter 2 ("Groenten"). Weg data integriteit.
Nu kan ik dit op twee manieren oplossen:
• serverside
• clientside
Omdat ik de server niet teveel wil belasten, wil ik het voor de gebruiker onmogelijk maken om een node uit het linker rijtje, te verplaatsen naar een van zijn eigen kinderen. Met andere woorden: als links "Groenten" wordt geselecteerd, moet het niet mogelijk zijn om rechts "Winter" of "Zomer" te selecteren. En als "Zomer" ook weer kinderen zou hebben, mogen die ook niet geselecteerd kunnen worden.
Ik zit hier nu een tijdje over te denken en heb besloten het clientside op te lossen, maar heb niet echt een idee hoe en of het ueberhaupt mogelijk is. De moeilijkheidsgraad van de javascript hangt voor een groot deel af van hoe ik de options van de select box noem:
• name="node[name][id][parent]" (bijvoorbeeld name="node[zomer][6][2]")
• name="name[id][parent]" (bijvoorbeeld name="zomer[6][2]")
Ik heb alleen te weinig ervaring met javascript om dit toch redelijk complexe probleem ineens op te lossen. Ik vraag daarom niet om een kant-en-klare oplossing, maar om jullie ideeen over hoe dit op te lossen: volgens welke conventie moet ik de options benamen om een goede oplossing te kunnen schrijven voor dit probleem? Welke andere problemen voorzie jij? Weet je of iemand eerder een soortgelijk probleem heeft gehad (ik kon zelf via de search niks vinden)?
code:
1
2
3
4
5
6
7
8
9
10
| +---------+----------+-----------+ | id | parent | name | +---------+----------+-----------+ | 1 | 0 | Home | | 2 | 1 | Groenten | | 3 | 1 | Fruit | | 4 | 1 | Vlees | | 5 | 2 | Winter | | 6 | 2 | Zomer | +---------+----------+-----------+ |
Ik ben nu bezig om de gebruiker een optie te geven pagina's kris-kras door de boom te verplaatsen:

Zie hier alleen het probleem: als iemand "Zomer" rechtstreeks onder "Home" wil zetten, is dat geen probleem. Ik verander dan de parent van "Zomer" van 2 (Groenten) naar 1 (Home). Maar het gaat fout als iemand "Groenten" onder een kind van "Groenten" wil zetten, zoals onder "Zomer". De nieuwe parent van "Groenten" wordt dan 6 ("Zomer"). De parent van "Winter" en "Zomer" blijft echter 2 ("Groenten"). Weg data integriteit.
Nu kan ik dit op twee manieren oplossen:
• serverside
• clientside
Omdat ik de server niet teveel wil belasten, wil ik het voor de gebruiker onmogelijk maken om een node uit het linker rijtje, te verplaatsen naar een van zijn eigen kinderen. Met andere woorden: als links "Groenten" wordt geselecteerd, moet het niet mogelijk zijn om rechts "Winter" of "Zomer" te selecteren. En als "Zomer" ook weer kinderen zou hebben, mogen die ook niet geselecteerd kunnen worden.
Ik zit hier nu een tijdje over te denken en heb besloten het clientside op te lossen, maar heb niet echt een idee hoe en of het ueberhaupt mogelijk is. De moeilijkheidsgraad van de javascript hangt voor een groot deel af van hoe ik de options van de select box noem:
• name="node[name][id][parent]" (bijvoorbeeld name="node[zomer][6][2]")
• name="name[id][parent]" (bijvoorbeeld name="zomer[6][2]")
Ik heb alleen te weinig ervaring met javascript om dit toch redelijk complexe probleem ineens op te lossen. Ik vraag daarom niet om een kant-en-klare oplossing, maar om jullie ideeen over hoe dit op te lossen: volgens welke conventie moet ik de options benamen om een goede oplossing te kunnen schrijven voor dit probleem? Welke andere problemen voorzie jij? Weet je of iemand eerder een soortgelijk probleem heeft gehad (ik kon zelf via de search niks vinden)?
"Real software engineers work from 9 to 5, because that is the way the job is described in the formal spec. Working late would feel like using an undocumented external procedure."