[js] Multi dim Array VS XML

[foske]

ik zit op dit moment met een dillema rondom data voor een tree binnen halen. In eerste instantie wilde ik gaan voor gehele tree inladen in tr's en dan dmv style = hide/show de tree laten zien. Maar dit gaf grote preformance problemen bij grotere tree's.

Toen kwam ik www.15seconds.com/demo/020424/index.html tegen, een mooi script dat simpel XML omzet in HTML dmv XSL. Helaas werkt dit alleen in IEX. Maar dat hield mij niet tegen om te kijken of ik het kon omzetten naar Mozilla en werkend houden in IEX (en liever nog meer andere, maar die hadden een iets wat lagere prioriteit).
Dagen later is dit nog steeds niet gelukt... Wel kan ik de xml data inlezen en benaderen maar de XSL er op los laten zodat het in zowel Mozilla als IEX werkt is helaas niet gelukt.. (ook niet met sarissa, http://sarissa.sourceforge.net/).

Nu heb ik XSL maar los gelaten aangezien deze toch echt liep te vervelen, en wilde ik alleen verder met XML als data feed, en dan dmv van JS en commando's als rowContainer.insertCell om dynamisch items toe te voegen. (minder overzichtelijk dan een XSL stylesheet, maar dit werkt )

Maar nu begin ik mijzelf eigenlijk af te vragen, is het niet handiger om XML helemaal los te laten, en verder te gaan met multi dimensionele array's om de boomstructuur op te vullen. Dan kan iedere redelijke browser met de tree omgaan nl.

De vraag komt eigenlijk neer op het volgende:
Wat zijn de haken en ogen aan Multi dim array's, ten opzichte van XML?

[Verwijderd]

Fossie schreef op dinsdag 04 januari 2005 @ 14:54:
De vraag komt eigenlijk neer op het volgende:
Wat zijn de haken en ogen aan Multi dim array's, ten opzichte van XML?

Er is maar één nadeel: je data is meteen voor niets anders geschikt. Met XML als een soort data-Espertanto zou je (bijvoorbeeld d.m.v. XSL) je data voor meerdere applicaties en interfaces geschikt kunnen maken. Als je dat niet wilt zie ik geen probleem met een geneste Array-structuur.

Ik zou het als ik jou was dan wel nog één stap verder trekken en gaan voor een Object-gebaseerde oplossing in JS. Kijk bijvoorbeeld eens naar mijn posts in [rml][ JS] Onmogelijk maken om ouder naar kind te verplaatsen[/rml] voor een eenvoudige opzet hiervoor.

[edit]
Ik zie net dat ik daar niet de laatste versie van dat scriptje heb gepost. Ik zal vanavond thuis nog even een betere versie opzoeken.

[ Voor 9% gewijzigd door Verwijderd op 04-01-2005 18:13 ]

[Verwijderd]

XML is natuurlijk wat transparanter dan een multi-dim. array, maar zo'n array scheelt je nogal wat overhead.

Kijk dus eens naar de verhouding tussen tags en werkelijke data. Is die heel erg laag, dan zou ik voor een multi-dim. array kiezen.

Heb je plannen om de data later ook in andere apps te gebruiken of te laten gebruiken door derden, dan is XML misschien een betere oplossing.

[foske]

owkej, dan denk ik dat het de array way wordt.alsvast bedankt voor jullie licht op de zaak

[Clay]

Het moment dat je een multidimensionale array nodig hebt (of denkt te hebben) zie ik (net als Blues) meestal als een omineus teken om toch voor een object based oplossing te gaan. ff door de theorie heenbijten, maar daarna is het veel makkelijker en overzichtelijker.

xsl lijkt me idd overkill, maar xml inladen en verwerken kan in IE en Moz. Daarnaast kan je dan ook nog in alletwee je data selecteren met xPath. Een wereld van mogelijkheden als je het mij vraagt.

[Bluestorm]

Ik zou nog willen toevoegen dat in mijn ervaring met grote hoeveelheden data, vooral IE een stuk sneller omgaat met XML dan met een grote objectstructuur.

[foske]

jah nou ik was eigenlijk al van plan om hem OO aan te pakken als ik voor array's zou gaan.

Over grote datastructuren, ik verwacht dat 400 items toch wel een max is. Maar goed, je weet nooit wat klanten allemaal bedenken en uiteraard wil je de beste preformance op de gemakkelijkste manier en dan ook nog cross browser

Ik denk dat mijn strategie wordt, om voor nu voor OO array's te gaan, en mocht het nu blijken dat XML beter/sneller/gemakkelijker is (misschien strax ook weer beter ondersteund door andere browsers?) dan de XML versie er naast ontwikkelen.

Bedankt

[Verwijderd]

Ik zou per definitie voor XML gaan. JS Arrays zijn wat performance onovertroffen, maar qua onderhoud en scheiding van logic en data ben ik persoonlijk een voorstander van XML. Bovendien als je ondemand data wilt gaan inladen, wil je dan ondemand arrays gaan outputten, en dan synchroon via hidden iframes gaan inladen? Dan ben je beter af met de mogelijkheden die browser hedendaags bieden met asynchrone xmlHttpRequests. Bovendien ben je veel flexibeler in het toevoegen van attributen aan een entry in je treeview. Wellicht vereis je in je applicatie wel dat je recordid's wilt koppelen aan een entry. Als je dat in een array wilt bakken blijf je aanklooien met nestings.

Als je op zoek bent naar een javascript based treeview heb ik evt. nog wel wat liggen. Waarom het wiel opnieuw uitvinden

[ Voor 19% gewijzigd door Verwijderd op 04-01-2005 21:18 ]

[foske]

Nou jouw tree ziet er idd wel veel belovend uit. Redelijk cross browser (Mozilla, IEX en op de mac safari 1.2 en Mozilla, opera nog niet).
Waar ik alleen beetje aan zit te denken, jij haalt iedere subtree opnieuw op van de server. In mijn geval zou dat dus een nieuw request naar de db zijn. Is dit niet veel zwaarder voor de server?

Daarnaast, ik ben al zo vrij geweest om het rar bestandje van je server af te halen (http://www.mschopman.demo...ew_v1.5/treeview_v1.5.rar) maar als deze uitpak en op mijn server zet, werkt het treeview.html niet, is dit het juiste bestand, of zit ik in de verkeerde?