Join MDN and developers like you at Mozilla's View Source conference, 12-14 September in Berlin, Germany. Learn more at https://viewsourceconf.org

Zaawansowane reguły

Artykuł ten, opisuje więcej zaawansowanych zasad składni.

Pełne zasady składni

Reguły składni opisującej dotychczas używane były w pewnych ilościach w kodzie źródłowym ale czasami będą potrzebne do wyświetlenia dane w sposób bardziej skomplikowany. Prosta reguła składni jest naprawdę tylko skrótem dla pełnej zasady składni, która jest opisana poniżej. Jak prosta zasada składni, tak i pełna zasada jest umieszczana w obrębie tagu rule.

Pełne reguły zawierają trzy tagi będące potomnymi, conditions stanami tagu, bindings opraw tagu i action akcji tagu, poprzez bindings tag jest nie zawsze potrzebny.

Element conditions jest użyty jako specyficzne kryterium odpowiadające dawanych źródeł. Możesz określić liczbę stanów odpowiadającą, wszystkim które muszą odpowiedzieć. W prostej regule składni, stany te są umiejscowione bezpośrednio w rule własnej elementu.

Jeżeli warunki spotkania odpowiadają zawartości źródła, zawartość ta umieszczona wewnątrz tagu actions jest wygenerowana. W prostej składni, zawartość jest umieszczona bezpośrednio wewnątrz rule.

Zasady

Kiedy drzewo, menu lub inny element z kodem źródłowym wygenerują zawartość, budowniczy szablonu pierwszy znajdzie źródło kierując się atrybutem ref. To potem powtarzamy nad całym tym źródłem będącego potomkiem zawartości. Stosuje się to w każdym stanie źródła. Jeśli warunki odpowiadają zawartości źródła, to zawartość w elemencie actions jest generowana dla tego źródła. Jeśli warunki są nie spełnione, zawartość nie jest generowana.

Element content

Element conditions może zawierać trzy elementy. Pierwszy do zawartość elementu content, który powinien zawsze występować tylko raz. Służy on za miejsce przechowywania podczas przeglądania zasobów przez budowniczego szablonu. Wyszczególnia on nazwę zmiennej, w której przechowywany jest odnośnik do głównego zasobu ( root resource ), podczas gdy warunki są analizowane w celu dopasowania. Główny zasób jest określony przez atrybut ref w elemencie zawierającym szablon.

Składnia elementu content zawiera następujący kod:

<content uri="?var"/>

Znak zapytania oznacza, że następujący potem tekst jest zmienną. Możesz więc użyć zmiennej 'var' wewnątrz pozostałych warunków. Oczywiście możesz nazywać zmienną jak tylko chcesz.

Element member

Następujący element jest elementem member, który jest używany do przeglądania zestawu potomnych zasobów. W terminach RDF oznacza to zasobnik taki jak Seq, Bag albo Alt. Powiedzmy, że masz listę miast opisanych w następującym fragmencie RDF/XML:

<RDF:Seq about="http://www.xulplanet.com/rdf/weather/cities">
  <RDF:li resource="http://www.xulplanet.com/rdf/weather/city/Paris"/>
  <RDF:li resource="http://www.xulplanet.com/rdf/weather/city/Manchester"/>
  <RDF:li resource="http://www.xulplanet.com/rdf/weather/city/Melbourne"/>
  <RDF:li resource="http://www.xulplanet.com/rdf/weather/city/Kiev"/>
</RDF:Seq>

<RDF:Description about="http://www.xulplanet.com/rdf/weather/city/Paris">
  <cityset:name>Paris</cityset:name>
</RDF:Description>

.
.
.

Możesz chcieć wyświetlić element wiersza w drzewie dla każdego opisu. Do zrobienia tego, użyj elementu member jak poniżej:

<tree id="citiesTree" datasources="weather.rdf"
      ref="http://www.xulplanet.com/rdf/weather/cities"> 
  <template>
    <rule>
      <conditions>
        <content uri="?list"/>
        <member container="?list" child="?city"/>
      </conditions>
    <rule>
  <template>
</tree>


Budowniczy szablonu rozpoczyna od przechwycenia wartości atrybutu ref, którą w tym przypadku jest http://www.xulplanet.com/rdf/weather/cities. Ten zasób będzie umieszczone w zmiennej 'list', jak zostało ustalone w znaczniku content. Możemy następnie pobrać pokrewne zasoby używając zmiennej 'list'.

Potem budowniczy szablonu widzi element member. Sprawia on, że budowniczy wędruje przez elementy potomne danego elementu. Element rodzic jest wyszczególniony przez atrybut container, a elementy dzieci - przez atrybut child. W przykładzie powyżej wartość atrybutu container to zmienna 'list'. Z tego wynika, że rodzic będzie wartością zmiennej list, która została ustawiona na główny zasób 'http://www.xulplanet.com/rdf/weather/cities'. Efektem tego będzie przejście przez listę dzieci tego zasobu.

Jeśli spojrzymy na powyższy RDF zobaczymy, że zasób "http://www.xulplanet.com/rdf/weather/cities" ma czworo dzieci, każdego dla innego miasta. Budowniczy szablonu wędruje przez każdego z nich, dopasowując go do wartości atrybutu dziecka ("child attribute"). W tym przypadku jest to po prostu wartość "city". Tak więc budowniczy wstawi zmienną "city" w miejsce wartości każdego zasobu potomnego.

Ponieważ nie ma więcej warunków, warunek pasuje do każdego z tych czterech zasobów i budowniczy wygeneruje zawartość dla każdego z tej czwórki. Oczywiście powyższy przykład nie ma żadnej zawartości. Dodamy ją później.

triple element

Następnym elementem jest element triple. Jest używany w celu sprawdzenia istnienia danego powiązania (potwierdzenie: prawda/fałsz) w danych źródłowych RDFu. Triple jest jak własność zasobu. Na przykład triple istnieje pomiędzy zakładką a jej adresem URL. Można to przedstawić następująco:

A Bookmark to mozilla.org  ->  URL  ->  www.mozilla.org

Znaczy to, że jest powiązanie ( triple ) pomiędzy zakładką 'A Bookmark to mozilla.org', a 'www.mozilla.org' poprzez własność URL. Pierwsza część tego wyrażenia jest nazwana podmiotem, druga - orzeczeniem, a trzecia to obiekt. Jako element triple wyrażałby się następująco:

<triple subject="A Bookmark to mozilla.org"
           predicate="URL"
           object="www.mozilla.org"/>

Zostało to nieco uproszczone w porównaniu z realnym kodem. Orzeczenie normalnie zawierałoby miejsce na nazwę, a podmiot byłby identyfikatorem id zasobu zakładki, a nie jej tytułem, jak powyżej. W rzeczywistości, tytuł zakładki byłby kolejnym powiązaniem w źródle danych, używanym z orzeczeniem Name.

Możesz wymienić podmiot i obiekt w elemencie triple na odnośniki zmiennych, a wtedy w miejsce zmiennych wstawione zostaną wartości. Jeśli żadna wartość nie zostanie zdefiniowana dla danej zmiennej, budowniczy szablonu poszuka zmiennej w źródle danych i przypisze ją danej zmiennej.

Powiedzmy, że chcemy dodać przewidywanie pogody do danych źródłowych miast. Można użyć następujących warunków:

<conditions>
  <content uri="?list"/>
  <member container="?list" child="?city"/>
  <triple subject="?city"
             predicate="http://www.xulplanet.com/rdf/weather#prediction"
             object="?pred"/>
</conditions>

Budowniczy szablonu będzie wędrował przez każde miasto jak wcześniej. Gdy dojdzie do triple, poszuka potwierdzenia w danych źródłowych RDFu czy istnieją przewidywania pogodowe dla danego miasta. Zmiennej 'pred' zostaną przypisane odpowiednie dane. Budowniczy powtórzy to dla każdego z czterech miast. Pojawi się dopasowanie, a budowniczy wygeneruje zawartość każdego miasta, które posiada prognozę. Jeśli miasto nie ma zasobu prognozowego, warunek nie pasuje do niego i nie zostanie wygenerowana zawartość dla takiego miasta. Zauważmy, że nie trzeba wstawiać 'rdf:' na początku orzeczenia, jako że tą część zakładamy wcześniej.

Moglibyśmy zastępować także object wartością wewnątrz linii. Na przykład:

<conditions>
  <content uri="?city"/>
  <triple subject="?city"
             predicate="http://www.xulplanet.com/rdf/weather#prediction"
             object="Cloudy"/>
</conditions>

Ten przykład jest podobny, ale wyszczególniliśmy fakt, że chcemy znaleźć dopasowanie do 'Cloudy'. Rezultat jest taki, że warunki będą pasować tylko dla miast, dla których prognoza zawiera 'Cloudy'.

Możemy dodać więcej powiązań, gdybyśmy wymagali więcej dopasowań. Na przykład we fragmencie powyżej, moglibyśmy chcieć sprawdzić temperaturę i prędkość wiatru. Aby to zrobić należy po prostu dodać następne powiązanie, które sprawdza dodatkowe zasoby. Warunek będzie spełniony, jeśli wszystkie powiązania dostarczą odpowiednich wartości.

Poniższy przykład sprawdzi dodatkowe powiązanie, warunek na nazwę miasta. Będzie to przypisane do zmiennej 'name'. Warunek będzie spełniony, wtedy i tylko wtedy gdy miasto ma zarówno nazwę jak i prognozę.

<conditions>
  <content uri="?list"/>
  <member container="?list" child="?city"/>
  <triple subject="?city"
             predicate="http://www.xulplanet.com/rdf/weather#name"
             object="?name"/>
  <triple subject="?city"
             predicate="http://www.xulplanet.com/rdf/weather#prediction"
             object="?pred"/>
</conditions>

Generowanie zawartości

Zawartość, którą generuje reguła, jest wyszczególniona wewnątrz elementu action. Powinna to być zawartość pod poziomów drzewa, elementów menu albo jakakolwiek, jaką chcesz wygenerować. Z tego wynika, że dla przykładu z pogodą powyżej, możesz użyć zmiennych 'name' albo 'pred' do wyświetlania miasta albo prognozy. Możesz użyć także zmiennych 'list' albo 'city', ale one przechowują zasoby, a nie tekst, więc nie będą mieć raczej znaczącej wartości dla użytkowników.

W prostej składni reguły używamy składni uri='rdf:*', aby zaznaczyć, gdzie powinna być wygenerowana zawartość. W pełnej składni ustawia się wartość atrybutu uri na zmienną, którą używasz w warunkach. Zwyczajowo będzie to zmienna przypisana do atrybutu child elementu member.

Complete Tree Example

Następny przykład pokazuje kompletne drzewo w czasie działania. Możesz zobaczyć plik RDF osobno Źródła RDF

Przykład 1 : Źródła

<tree id="weatherTree" flex="1" datasources="weather.rdf"
      ref="http://www.xulplanet.com/rdf/weather/cities">
  <treecols>
    <treecol id="city" label="City" primary="true" flex="1"/>
    <treecol id="pred" label="Prediction" flex="1"/>
  </treecols>

  <template>
    <rule>
      <conditions>
        <content uri="?list"/>
        <member container="?list" child="?city"/>
        <triple subject="?city"
                predicate="http://www.xulplanet.com/rdf/weather#name"
                object="?name"/>
        <triple subject="?city"
                predicate="http://www.xulplanet.com/rdf/weather#prediction"
                object="?pred"/>
      </conditions>
      <action>
        <treechildren>
          <treeitem uri="?city">
            <treerow>
              <treecell label="?name"/>
              <treecell label="?pred"/>
            </treerow>
          </treeitem>
        </treechildren>
      </action>
    </rule>
  </template>
</tree>

Dwie kolumny pokazują nam się w tym drzewie, jedna wyświetla cechy nazwy każdego pod poziomów, a reszta wyświetla przewidywane cechy.

Jeśli użyjemy flagi dont-build-content zmniejszymy drzewo, zamieniając element content z elementem treeitem.

Dodawanie dodatkowych wiązań

Końcowy element możesz dodać wewnątrz reguły elementu bindings. Wewnątrz jego, możesz położyć jeden lub więcej elementów binding. Oprawiając w zasady mamy taką samą składnię jako potrójny i spełnia prawie tą samą funkcję. Na przykład w przykładzie poniżej możemy dodać następujące oprawy:

<bindings>
  <binding subject="?city"
             predicate="http://www.xulplanet.com/rdf/weather#temperature"
             object="?temp"/>
</bindings>

Taka oprawa przechwyci zasoby temperaturowe każdego drzewa i przypisze je do zmiennej 'temp'. Jest to bardzo podobne do tego, co robi powiązanie. Różnica jest taka, że oprawa nie jest sprawdzana, gdy próbuje sprawdzić warunki. Oznacza to, że miasto musi mieć nazwę i prognozę do wyświetlenia, chociaż nie ma znaczenia czy ma temperaturę. Jednak, jeśli ma, będzie ona umieszczona w zmiennej 'temp', żeby mogła być użyta w akcji. Jeśli miasto nie ma temperatury, zmienna "temp" będzie miała pusty string.

Następnie, poszukamy jak zapisać stanowisko elementów XUL.

Autorzy i etykiety dokumentu

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