Please note, this is a STATIC archive of website developer.mozilla.org from 03 Nov 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.

Drzewa i szablony

 

Zawartość artykułu opisuje jak używać szablonów wraz z drzewami.

Dodajemy źródło danych do drzewa

Kiedy używamy drzewa, często korzystamy z szablonu, aby zbudować jego zawartość, kierując dużą ilością hierarchicznych danych. Używając szablonu z drzewem stosujemy bardzo często podobną składnię z innymi elementami. Aby dodać datasources i atrybut ref do elementu tree, który określa źródło danych i węzeł podstawy wyświetla.

Następujący przykład odwołuje się do historii kodu źródłowego:

<tree datasources="rdf:history" ref="NC:HistoryByDate"
          flags="dont-build-content">

Jak opisano w poprzednim temacie, drzewa mogą używać programów do budowy drzew dla generatora szablonów zamiast normalnej zawartości programów do budowy. Oznacza to, że elementy te nie będą utworzone dla każdego wiersza w drzewie, robiąc go bardziej efektywnym. Atrybuty flags ustawią wartość dont-build-content,jak w przykładzie powyżej, sygnalizując użycie generatora drzew. Jeśli opuszczasz ten atrybut, generator zawartości zostanie użyty. Możesz zobaczyć różnice używając Inspektora Mozilla DOM w drzewie z lub bez flagi.

Jeśli używasz do budowy zamiast budowniczego zawartości, notatki że ta zawartość nie będzie generalnie pobierana do budowy aż do momentu kiedy nie będziesz tego potrzebował. W hierarchicznych drzewach, potomek-dziecko nie będzie brał generowanego tekstu aż węzeł rodzic nie zostanie otwarty przez użytkownika.

W szablonie, jest po jednej treecell dla każdej kolumny w drzewie. Komórki powinny mieć atrybut label do ustawiania etykiety komórek. Jest to normalne ustawienie własności w RDF, tak więc etykieta jest pobierana z kodu źródłowego.

Template-built Tree Example

Następujący przykład demonstruje zbudowany szablon drzewa, w tym przypadku dla pliku systemowego:

Przykład 1 : Źródła

<tree id="my-tree" flex="1"
       datasources="rdf:files" ref="file:///" flags="dont-build-content">
  <treecols>
    <treecol id="Name" label="Name" primary="true" flex="1"/>
    <splitter/>
    <treecol id="Date" label="Date" flex="1"/>
  </treecols>

    <template>
      <rule>
        <treechildren>
          <treeitem uri="rdf:*">
            <treerow>
              <treecell label="rdf:https://home.netscape.com/NC-rdf#Name"/>
              <treecell label="rdf:https://home.netscape.com/WEB-rdf#LastModifiedDate"/>
            </treerow>
          </treeitem>
        </treechildren>
      </rule>
    </template>
</tree>

W ty miejscu, drzewo zostało utworzone z dwoma kolumnami, dla nazwy i daty pliku. Drzewo powinno zostać wyświetlone jako lista plików w katalogu głównym. Użyto tylko jednej zasady, ale ty możesz dodać inne, jeśli tego potrzebujesz. Tak samo z innymi szablonami, atrybut uri na elemencie wskazuje gdzie ma zacząć generować zawartość. Dwie komórki dostają nazwę i datę z kodu źródłowego i umieszcza ich wartość w etykiecie komórki.

Przykład pokazuje dlaczego atrybut uri staje się użyteczny. Zauważ jak to było na pozycji drzewa w przykładzie, nawet chociaż to nie jest prosty potomek elementu reguły. Potrzebujemy położyć ten atrybut na tych elementach, na których potrzebujemy uzyskać powtórzony kod. Ponieważ nie chcemy wielokrotnego elementu treechildren, nie chcemy to tam położyć. Skutecznie, elementy zewnętrzne (lub powyższe) elementu z atrybutem uri nie są duplikowane podczas gdy elementy z atrybutem uri i elementy wewnątrz są duplikowane dla każdego źródła.

Zaznaczony w obrazku element to potomek - dziecko, który jest umieszczony poniżej elementu z poziomu górnego, który został dodany automatycznie. XUL wie jak dodać element dziecka kiedy szablon lub zasady stanowią wartość elementu drzewa lub elementu menu. Generując elementy drzewa jako zagnieżdżone i konieczne oparte na dostępnych danych RDF.

Image:rdfoutl1.jpg

Interesującą partię danych z kodem źródłowym RDF jest w wartości tych zasobów, i edytujesz tylko zasoby decydując kiedy dane są potrzebne. Wyznacza to wartość na jaką głębokość w zasobach hierarchii są nie możliwe do utworzenia aż do nawigacji zasobami poprzez węzeł w drzewie. Stało się to użytecznym dla pewnego kodu źródłowego gdzie dane są dynamicznie możliwie.

Sortowanie kolumn

Jeśli wypróbujesz poprzedzający przykład, moglibyśmy zaznaczyć to w co lista nie jest posortowana. Drzewa które generują dane z kodu źródłowego posiada nieobowiązkową zdolność posortować ich dane. Możemy posortować każdy podnoszący się i obniżający na jakiejkolwiek kolumnie. Użytkownik może zmienić posortowane kolumny i kierunek poprzez kliknięcie nagłówka kolumny. Właściwości sortowania nie są dostępne dla wartości drzew statycznych, chociaż możemy pisać skrypty zawierające dane.

Sortując angażuje trzy atrybuty, które powinny być umieszczone w kolumnach. Pierwszy atrybut, sort powinien być ustawiony na własności klucza sortowania używanego w RDF. Często, może to być użyta taka sama nazwa etykiety w komórce kolumny. Jeśli ustawisz sortowanie na kolumnę, to wtedy będą sortowane w niej dane. Użytkownik może zmienić kierunek sortowania klikając w nagłówek kolumny. Jeśli nie ustawisz atrybutu sort w kolumnie, dane nie mogą być sortowane w tej kolumnie.

Atrybut sortDirection jest używany do ustawienia kierunku w którym kolumny będą sortować domyślnie. Poszczególne możliwe cechy:

  • ascending: dane są wyświetlane rosnąco
  • descending: dane są wyświetlane malejąco
  • natural: dane są wyświetlone w rozkazie naturalnym , które znaczy polecenie danych jest przechowywane w kodzie źródłowym RDF.

Atrybut finalny, sortActive powinien być ustawiony na true dla jednej kolumny, jeden którego wybraliśmy będzie sortowany domyślnie.

Chociaż sortowanie działa bez zarzutów i prawidłowo tylko z tamtymi narzędziami, możesz także użyć klasę stylu sortDirectionIndicator w kolumnie, w której będzie ona sortowana. Będzie powodować mały trójkąt pojawiający się nagłówek, który wskazuje kierunek sortowania. Jeśli nie chcesz tego robić, możesz dalej sobie sortować kolumny ale nie uzyska wskazówek dotyczących kierunku aktualnego sortowania.

Poniższy przykład pokazuje zmiany kolumn we wcześniejszym przykładzie poprzez dołączenie extra własności:

<treecols>
  <treecol id="Name" label="Name" flex="1" primary="true"
            class="sortDirectionIndicator" sortActive="true"
            sortDirection="ascending"
            sort="rdf:https://home.netscape.com/NC-rdf#Name"/>
  <splitter/>
  <treecol id="Date" label="Date" flex="1" class="sortDirectionIndicator"
           sort="rdf:https://home.netscape.com/WEB-rdf#LastModifiedDate"/>
</treecols>

Stały rozmiar kolumn

Jedna dodatkowa rzeczą możesz chcieć zrobić wytrzymałe kolumny, które są aktualnie sortowane, więc to jest zapamiętywane pomiędzy sesjami. Aby zrobić to, użyjmy atrybutu persist na każdym treecol elemencie. Znajduje się tam pięć atrybutów kolumn, które będą upierały się, aby zapisać width (długość) kolumn, kolumna rozkazu, czy kolumna jest jawna, która kolumna jest aktualnie posortowana i sortuje instrukcje. Poniższy przykład pokazuje przykładowe kolumny:

<treecol id="Date" label="Date" flex="1"
             class="sortDirectionIndicator"
             persist="width ordinal hidden sortActive sortDirection"
             sort="rdf:https://home.netscape.com/WEB-rdf#LastModifiedDate"/>

More details about the persist attribute will be described in the later section.

Additional Rule Attributes

Dodawanie atrybutów zasad

Tutaj mamy dwa dodatkowe atrybuty, które mogą zostać dodane jako elementy zasad, które pozwolą na określenie pewnych specjalnych okoliczności. Oba atrybuty są typu boolean.

iscontainer
jeśli ten atrybut jest ustawiony na wartość true, następnie zasady dopasują kod źródłowy, który posiada potomka-dziecko. Na przykład, możemy używać zasad aby dopasować foldery zakładek. Jest to wygodny jako kod źródłowy RDF nie potrzebującego wszelkich specjalnych atrybutów wskazujących na to.
isempty
jeśli ten atrybut jest ustawiony na wartość true, następnie zasady dopasują kod źródłowy tak aby nie posiadać potomka - dziecka.

Dwa powyższe atrybuty są naprawdę swoimi przeciwieństwami. Zasoby mogą być w zbiornikach i będą puste jako dobre(?). Kiedykolwiek, różnice pochodzą z kodu, to nie będzie zbiornikiem. Na przykład, folder zakładek jest pojemnikiem ale to siła nie może mieć potomka. Kiedykolwiek, pojedyncza zakładka lub separator nie są żadnym pojemnikiem.

Możesz połączyć te dwa elementy z innymi aplikacjami, atrybutami dla określonych zasad.

Następnie, zobaczymy trochę kodu źródłowego dostarczonego przez Mozillę.

Autorzy i etykiety dokumentu

Etykiety: 
 Autorzy tej strony: fscholz, teoli, Ptak82, Mgjbot, Minh Nguyen
 Ostatnia aktualizacja: fscholz,