>
> Hallo,
> also jetzt hab ich mein DOM beisammen...
> Dazu habe ich Deinen Vorschlag nach elementen suchen zu lassen
> aufgefriffen:
eigentlich hatte ich gerade gesagt, das suchen nach IDs in beliebiger
tiefe lagsam ist.... vielmehr muss man genau sagen, wo der gesuchte
Knoten zu finden ist... mit Pfad... siehe vorherige Beispiele..
>
> <root>
> <element1 type="DBFolder" ID="123">
wieso hast Du denn noch IDs in Attributen, wenn die ID doch schon am
element namen h�ngt?
> <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
wie schon gesagt, m�sstet Du den ganzen Pfad mitschicken...
in diesem Fall ist es ok, weil element1 auf oberster ebene ist, aber f�r
element4, m�sste man sowas wie tree.asp?Action=open&el=1/2/4
schreiben...
>
> 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 :-)
ja, so ziemlich... hauptsache es ist 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
> ....
ok... habe gerade einen lichtblick... ich hab es vorher nicht ganz
durchdacht, sondern nur die recordset-Methoden im Kopf nach XML
�bersetzt...
im Recordset m�sste man in einem Recordset st�ndig rumspringen um die
ganzen children rekursiv abzulaufen... aber in XML ist das ja alles viel
einfacher.. da sind ja die Kinder direkt errreichbar... das hatte ich
nicht bedacht... ignorier was ich weiter oben geschrieben habe.
Du brauch nur die offenen IDs speichern, m�glichst so: ",1,4,6,8,9,"
(mit absicht vorne und hinten noch kommas drangesetzt)...
Dann l�ufst du einfach den tree ab und entscheidest bei jedem node mit
instr(offeneIDs, ","& dieID &",")<>0, ob du tiefer eintauchst und die
children noch ausgibst... easy..
>
> -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
ja, aber das ist nicht so problematisch, wenn moistens gelesen 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?
Nicht gut... da ist Apllication.lock performanter, als wenn Due in
locking selber implementierst...
Am besten f�gst Du einfach ein und sonst nichts... das
freethreadedDocumentDoc ist ja gerade f�r parallelem Zugriff von
mehreren Threads geschrieben, d.h. entweder bekommt der andere User die
�nderung noch mit, oder eben nicht... dann bekommt er es eben erst beim
n�chsten mal mit... kein Problem...
Du solltest nur wenn Du gr�ssere Unterb�ume einf�gen willst, den
Unterbaum erst komplett aufbauen und dann den gesamten unterbaum
anh�ngen, statt erst die Wurzel des Unterbaumes an das dokument
anzuh�ngen und dann den Rest des unterbaums...
Gruss,
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
