Hallo,
also jetzt hab ich mein DOM beisammen...
Dazu habe ich Deinen Vorschlag nach elementen suchen zu lassen aufgefriffen:
<root>
<element1 type="DBFolder" ID="123">
<element2 type="DBFile" ID="22"></element2>
<element3 type="FileFolder" Path="/Pfad/"></element3>
<element4 type="FileDoc" Path="/Pfad/dokument.html"></element4>
</element3>
</element1>
<element5 type="DBFolder" ID="232">
<element6 Type="DBFile" ID="23"></element6>
</element7>
....
</root>
Demnach habe ich zwei Szenarien:
�ffnen:
tree.asp?Action=open&el=1
Diesen querystring f�ge ich der Session hinzu:
session("Tree")= session("Tree") + request.querystring("el")
Danach gebe ich den Baum aus:
-split der session-variable mit einem Deliminator (",")
For each - schleife:
-Node anzeigen
-Children zugreifen und anzeigen
-fertig
Zweites Szenario schlie�en:
tree.asp?action=close&el=1
-Die Session wieder manipulieren:
session ("tree") = replace(session(tree),"delim","")
Die Namen sind ja im obigen xml einzigartig
Meine frage:
-Ist das xml so in deinem Sinne :-)
-In deinem Beispiel hast Du irgendwie abh�ngigkeiten dargestellt:
open=1|2|3,4|5
Ich beziehe mich auf "3,4" Das brauche ich doch in meiner Idee ja nicht, da
jedes Element entweder offen oder zu ist und wenn es eben offen ist, dann
werden ja nur die Children angezeigt (wenn es ein Ordner ist, was ja klar
ist, weil ja der Baum nur neu geladen wird, wenn man auf einen Ordner klickt
....
-Du meintes am besten ist das DOM in einer Application-Variable gepackt...
Denke ich auch so. Nun gibt es aber mehrere Szenarien wo sich der Baum
�ndert (Dokument hinzuf�hen, Dokument l�schen, ordner....)
Der Zeitunterschied zwischen UserA und UserB die auf das DOM lesend und
schreibend zugreifen:
UserA beginnt in das DOM ein Dokument reinzuschreiben und UserB beginnt
knapp danach das DOM zu lesen....
Zwei L�sungen habe ich:
-Application Lock:
Nicht so toll meiner Meinung nach weil ja der Baum zentraler Bestandteil ist
und oft aufgerufen wird
-Alternativ k�nnte ich am beginn des DOM einen Node hinzuf�gen:
<root>
<isDirty value="true|false" />
<element1....
</root>
Wenn also ein User den Baum �ndert wird zuerst (m�glichst schnell) das
isDirty auf true gesetzt. Wenn der UserB dann das DOm beginnt zu lesen
erkennt der, da� der Baum u.U. nicht passt....
Da kann man dann mehrere sachen machen:
-Wait
-Meldung �ber die Situation
Was meinst Du zu alle dem?
Gru� Mansur
> Ein anderes problem ist das speichern der navigationsdaten, bzw. welcher
> teilbaum ge�ffnet ist...
> Da reicht n�mlich nicht ein einfaches show.asp?open=4,7,9,12,3,23
> Denn obwohl man den knoten IDs geben k�nnte:
>
> <root>
> <element id="1" name="ordner1" type="folder">
> <element id="5" name="xml.doc" type="file">
> </element>
> </element>
> <element id="2" name="ordner2" type="folder">
> </element>
> <element id="3" name="ordner3" type="folder">
> <element id="4" name="test.xml" type="file">
> </element>
> </element>
> </root>
>
> Enth�lt eine ID keine Information �ber die Position des kotens im
> gesamt-Baum, d.h. wenn man so versucht auf den Knoten zuzugreifen:
> oDom.getSingleNode("//element[id='4']")
> Dann muss der gesamte Baum danach durchsucht werden...
>
> Man muss also immer den genauen Weg spezifizieren, dann ist das DOM sehr
> schnell, also:
> oDom.getSingleNode("/root/element[id='3']/element[id='4']")
>
> Das impliziert aber leider, das man bei f�r die information welcher
> knoten ge�ffnet ist eher sowas in den querystring schreiben muss:
> show.asp?open=2/4,7/13/8/4,9/12/3/23
> Damit k�nnte aber der Querystring aber bald zu klein werden, weshalb es
> keine schlechte idee ist diese informationen woanders zu speichern, z.B.
> in einer Session und nur die �nderungen(Knoten x/y/z �ffnen; Knoten
> 1/2/3 schliessen) per Querystring zu schicken...
>
> ** Optimierungsm�glichkeiten:
> - wenn du die ID in Attribute packst, dann wird das suchen nach knoten
> �ber langsame string-compares gemacht...
> Das suchen nach elementnamen geht schneller, weil eine hash-Table von
> allen im XML-Dok vorhandenen Elementnamen angelegt wird, in der sie
> einer ID zugewiesen werden... Der Vergleich funktioniert dann �ber
> diese ID statt �ber strings...
> D.h. man sollte seine daten so speichern, statt wie in meinem ersten
> beispiel oben:
> <root>
> <element1 name="ordner1" type="folder">
> <element5 name="xml.doc" type="file" />
> </element>
> <element2 name="ordner2" type="folder" />
> <element3 name="ordner3" type="folder">
> <element4 name="test.xml" type="file" />
> </element>
> </root>
>
> - dieses hierarchische selektieren funktioniert am besten, wenn an jedem
> verzweigungspunkt m�glichst wenige unterknoten zu durchsuchen sind, am
> besten max. 10...
> Wenn du sehr breite b�ume hast kannst du dieses selektieren
> verschnellern, wenn du nicht alle unterknoten direkt unter den parent
> steckst, sondern nach der letzten ziffer der id noch mal in
> unterschiedliche pseudo-unterordner packst:
> <root>
> <element5>
> <sub1>
> </sub1>
> <sub2>
> <element32 />
> <element112 />
> <element2 />
> </sub2>
> <sub3>
> </sub3>
> <sub4>
> <element4 />
> <element24 />
> <element74 />
> </sub4>
> <sub5>
> </sub5>
> ....
> ...
> </element5>
> </root>
>
>
> Hoffe das hilft dir ein wenig...
>
> Claudius
>
>
>
>
> | [aspdecoffeehouse] als [EMAIL PROTECTED] subscribed
> | http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv
> | Sie k�nnen sich unter folgender URL an- und abmelden:
> | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffeehouse.asp
>
| [aspdecoffeehouse] als [email protected] subscribed
| http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv
| Sie k�nnen sich unter folgender URL an- und abmelden:
| http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffeehouse.asp
