Zamierzam napisać od podstaw prosty komponent drzewka, język i
środowisko nie gra roli.
Z punktu użytkownika będzie to struktura, gdzie mamy listę (a raczej
wektor, bo nie będzie to lista linkowana a rozszerzana tablica) węzłów
pierwszego poziomu. Każdy z nich (jeśli ma dzieci) będzie miał wektor
swoich węzłów i tak dalej.
Każdy z tych węzłów może mieć właściwość expanded lub nie, więc węzeł
który jest expanded lub nie, może mieć dzieci z których jedne są
expanded lub nie.
Jak mam jedną listę, która przechodzi przez wszystkie te listy, to
wyświetlanie tego już jest łatwe.
A co mi chodzi - mam drzewko:
a
b
d
e
c
f
g
wcięcia są ważne
Fizycznie elementy są w kilku listach:
root-> a, g
a->b,c
b->d,e
c->f
Podczas gdy mamy jedną listę do wyświetlenia:
a b d e c f g ("pozycją wizualną" nazwę a=0,b=1,d=2 etc)

Są dwa problemy:
1. znaleźć pozycję wizualną dla węzła
2. znaleźć węzeł dla zadanej pozycji wizualnej
Punkt 2 jest łatwy, jeśli istnieje lista węzłów jak a b d e c f g, przez
chwilę myślałem że to rozwiązanie.
Dla operacji expand/collapse musimy przemieścić blok i wstawić lub
usunąć, co jest dopuszczalne.
Punkt 1 nadal trudny.
Poza tyym, co gorsze - jeśli dodajemy węzeł, musimy zlokalizować go
przez punkt 1, a poza tym dodanie jednego wymaga rozsunięcia, więc gdy
dodamy wiele, mamy Move wiele razy co jest zbyt wolne.

Drugie rozwiązanie (kiedyś go użyłem dla drzewka, ale było to
rozwiązanie bardzo skomplikowane, może da się prościej):
Węzeł (czy lista wezłów - nie ma tu wielkiej różnicy) ma pole
VisibleCount oznaczające wielkość całej rozwiniętej częściowo podgałęzi.
Tutaj dodawanie tak nie spowalnia, bo trzeba updatować jedynie
VisibleCount parenta, parenta->parenta, aż do korzenia.
Ale punkty 1 i 2 pozostają trudne.

Czy jest jakiś wydajny algorytm na to?

do góry

W dniu 2015-03-21 o 18:36, Borneq pisze:
> Zamierzam napisać od podstaw prosty komponent drzewka, język i
> środowisko nie gra roli.

Jak to jest w bibliotekach Javy czy C# gdzie mamy zastosowanie wzorca
Model-View-Controller (MVC) ?

do góry

On 2015-03-22 06:55:47 +0000, Borneq said:

> W dniu 2015-03-21 o 18:36, Borneq pisze:
>> Zamierzam napisać od podstaw prosty komponent drzewka, język i
>> środowisko nie gra roli.
>
> Jak to jest w bibliotekach Javy czy C# gdzie mamy zastosowanie wzorca
> Model-View-Controller (MVC) ?

Mogłbym Ci pomóc (ale nie napisać za Ciebie pracę zaliczeniową w
całości) napisać taki algorytm w JS z reprezentacją wizualną w DOM.
Chcesz?

do góry

W dniu 2015-03-22 o 09:29, Dariusz Jakubowski pisze:
> Mogłbym Ci pomóc (ale nie napisać za Ciebie pracę zaliczeniową w
> całości) napisać taki algorytm w JS z reprezentacją wizualną w DOM. Chcesz?

Dzięki za zainteresowanie.
Nie pytam się o gotowca, język też nie jest ważny. Tylko jestem ciekawy
algorytmu pomiędzy Modelem a Widokiem, jakich struktur, pól warto użyć.
Bo np. odrzucam listę wizualnych z powodu tego , że trzeba ją updatować
przy dodawaniu elementów a tych może być 100 tysięcy.
Czy trzymanie VisibleCount jest jedynym dobrym rozwiązaniem? Kiedyś
pisałem właśnie komponent drzewka oparty o to, ale wyszedł bardzo
skomplikowany. Teraz chciałem napisać prosty, elegancki, z mniejszą
ilością kodu a co najważniejsze, łatwiejszy do zrozumienia.

Pozdrawiam

do góry

On 2015-03-22 08:39:04 +0000, Borneq said:

> W dniu 2015-03-22 o 09:29, Dariusz Jakubowski pisze:
>> Mogłbym Ci pomóc (ale nie napisać za Ciebie pracę zaliczeniową w
>> całości) napisać taki algorytm w JS z reprezentacją wizualną w DOM. Chcesz?
>
> Dzięki za zainteresowanie.
> Nie pytam się o gotowca, język też nie jest ważny. Tylko jestem ciekawy
> algorytmu pomiędzy Modelem a Widokiem, jakich struktur, pól warto użyć.
> Bo np. odrzucam listę wizualnych z powodu tego , że trzeba ją updatować
> przy dodawaniu elementów a tych może być 100 tysięcy.
> Czy trzymanie VisibleCount jest jedynym dobrym rozwiązaniem? Kiedyś
> pisałem właśnie komponent drzewka oparty o to, ale wyszedł bardzo
> skomplikowany. Teraz chciałem napisać prosty, elegancki, z mniejszą
> ilością kodu a co najważniejsze, łatwiejszy do zrozumienia.
>
> Pozdrawiam

Chyba rozumiem. Model powinien wyglądać tak:
Item {expanded, Bool, hasMany: Item as children, belongsTo: Item as parent}
Rekordy są wszystkie w jednej tablicy na tym samym poziomie i mają
swoje pole id (to konieczne). Ręcznie tworzysz pierwszy rekord o id 0
i nazywasz go Root albo / (albo w ładniejszej wersji wyszukujesz
wszystkie które nie mają parent, wtedy możesz mieć kilka rootów). Zeby
znaleźć lokalizacje jakiegokolwiek modelu robisz:
var item = <przekazany rekord>
var position = []; do {
position.push(item.id);
item = item.parent;
} while (item)
position = position.reverse().join(' => ');
print(position);
Punkt 2 mowisz ze wiesz to nie bede tlumaczyl. Liczenie rozwinietych
pozycji nie moze byc trzymane w jakiejś właściwosci, najwyzej cachowane
az do kolejnej zmiany. Mozesz sobie napisac funkcje getVisibleCount:
<sprawdzasz czy model mial aktualizacje, jak tak to kontunuujesz a jak
nie to zwracasz ostatni wynik>
var item = <przekazany rekord albo root>
var visible = 0;
if (item.expanded && item.children) {
visible += 1; // dodajemy aktualny wezem do visible;
// mapujemy ilosc visible podwezlow i sumujemy wszystkie. To rekurencja
visible += item.children.map(function (node) {
return getVisibleCount(node);
}).sum();
} do

return visible;


Wydaje mi się że to w miare rozsądny algorytm. Zawsze możesz podejrzeć
jak to robi jakiś inny framework i zgapić.

do góry

W dniu 2015-03-22 o 10:05, Dariusz Jakubowski pisze:
> Chyba rozumiem. Model powinien wyglądać tak:
> Item {expanded, Bool, hasMany: Item as children, belongsTo: Item as
> parent}
> Rekordy są wszystkie w jednej tablicy na tym samym poziomie i mają swoje
> pole id (to konieczne).

Wielkie dzięki! Spróbuję zrozumieć.
Czy będzie tak, że dla
a
b
d
e
c
f
g
będzie
root, id=0
a, id=1, parent=0
b, id=2, parent=1
d, id=3, parent=2
e, id=4, parent=2
c, id=5, parent=1
f, id=6, parent=5
g , id=7, parent=0
?
Nie bardzo rozumiem "hasMany: Item as children"

do góry

On 2015-03-22 09:22:52 +0000, Borneq said:

> W dniu 2015-03-22 o 10:05, Dariusz Jakubowski pisze:
>> Chyba rozumiem. Model powinien wyglądać tak:
>> Item {expanded, Bool, hasMany: Item as children, belongsTo: Item as
>> parent}
>> Rekordy są wszystkie w jednej tablicy na tym samym poziomie i mają swoje
>> pole id (to konieczne).
>
> Wielkie dzięki! Spróbuję zrozumieć.
> Czy będzie tak, że dla
> a
> b
> d
> e
> c
> f
> g
> będzie
> root, id=0
> a, id=1, parent=0
> b, id=2, parent=1
> d, id=3, parent=2
> e, id=4, parent=2
> c, id=5, parent=1
> f, id=6, parent=5
> g , id=7, parent=0
> ?
> Nie bardzo rozumiem "hasMany: Item as children"

children to dzieci czyli:
> root, id=0, children= 1,7
> a, id=1, parent=0, children= 2,5
> b, id=2, parent=1, children= 3,4
> d, id=3, parent=2
> e, id=4, parent=2
> c, id=5, parent=1 , children=6
> f, id=6, parent=5
> g , id=7, parent=0
Dane się teoretycznie powielają ale to mocno ułatwi i przyspieszy algorytm

do góry

W dniu 2015-03-22 o 10:26, Dariusz Jakubowski pisze:
> children to dzieci czyli:
>> root, id=0, children= 1,7
>> a, id=1, parent=0, children= 2,5
>> b, id=2, parent=1, children= 3,4
>> d, id=3, parent=2
>> e, id=4, parent=2
>> c, id=5, parent=1 , children=6
>> f, id=6, parent=5
>> g , id=7, parent=0
> Dane się teoretycznie powielają ale to mocno ułatwi i przyspieszy algorytm
>
Czyli oprócz listy głównej, każdy nie element nie liść będzie miał listę.
Jak do b wstawiamy trzeci element?

do góry

On 2015-03-22 09:47:42 +0000, Borneq said:

> W dniu 2015-03-22 o 10:26, Dariusz Jakubowski pisze:
>> children to dzieci czyli:
>>> root, id=0, children= 1,7
>>> a, id=1, parent=0, children= 2,5
>>> b, id=2, parent=1, children= 3,4
>>> d, id=3, parent=2
>>> e, id=4, parent=2
>>> c, id=5, parent=1 , children=6
>>> f, id=6, parent=5
>>> g , id=7, parent=0
>> Dane się teoretycznie powielają ale to mocno ułatwi i przyspieszy algorytm
>>
> Czyli oprócz listy głównej, każdy nie element nie liść będzie miał listę.
> Jak do b wstawiamy trzeci element?

Tak. A jak chcesz dodac gdzies element to tworzysz nowy Item, ustawiasz
mu parent a parentowi dodajesz do children id tego Itema

do góry