mozilla

Revision 275594 of 模板:编译Rule

  • Revision slug: User_talk:Dongdong/编辑­Rule
  • Revision title: 模板:编译Rule
  • Revision id: 275594
  • Created:
  • Creator: Dongdong
  • Is current revision? No
  • Comment 472 words added, 2 words removed

Revision Content

上一页User_talk:Dongdong                                下一页User_talk:Dongdong/产生结果

Query
Edit section

一个XUL模板是由一个查询条件和一系列Rules条件组成的。一个查询条件中包括了关于如何从数据源中取数据的指示。不同的数据源有不同的语法。 例如,如果是SQLite数据源,一个SQL语句就是查询条件。这就能产生一组结果并以此得到最终想要的结果。如果是RDF或XML,查询条件就包括了一 组用于浏览RDF图和DOM结点的指示。查询条件是在query标签中声明的(Firefox3中支持这个语法,Firefox2中只支持RDF数据源并 且没有query这个标签),query标签直接放在template标签内。query是用来产生一组结果集的。

Rules
Edit section

模板也包括了一组规则(Rules),用于从不同的条件产生不同的结果。还有在后面我们要谈到的attribute置换语法,用来得到并变更从模板中得到的结果值。规则是用rule标记定义的,你可以定义多个规则。从query得到的结果都会经过规则的过滤,最终得到的数据就是满足规则的数据。需要注意的是,数据找到满足条件的第一个规则后,其它的规则将不再对该数据进行过滤。例如,第一个规则如果过滤书,那么第二个规则就只能对杂志进行过滤。也就是说,数据过滤一个就少一个。按这种方式,不同的数据产生不同的结果。

在很多情况下,你只需要一个规则,因为你想让所有数据按照一个规则过滤。比如,你在产生一个列表框时,只通常只会用一个规则。如果只需要一个规则,可以不定义rule标记。一个没有任何规则的模板会对每个数据进行无条件过滤。

Template语法概要
Edit section

下面是模板语法概要

<vbox datasources="http://www.xulplanet.com/ds/sample.rdf"
         ref="http://www.xulplanet.com/rdf/A" flex="1">
  <template>
    <query>
      -- query content goes here --
    </query>
    <rule>
      -- rule content goes here --
    </rule>
    <rule>
      -- rule content goes here --
    </rule>
  </template>
</vbox>

 

Query/rule 的编译与结果集的惰性产生机制

当模板构建器开始处理数据,并在它开始加载数据源后,它必须编译Query和Rule.这个步骤包括分析查询规则并将之转换为内部数据结构。因此,如果动态改变规则将不会有任何效果。然而,通过调用builder.rebuild重构模板时,会对查询规则进行重新编译,并再次应用模板。这就意味着你可以用DOM方法来改变规则,重构模板然后得到新的不同的结果。

一旦模板构建器编译完规则,查询和产生结果集的过程就开始了。模板构建器产生结果集的过程是很懒惰的,它只在需要的时候才进行处理。例如,考虑下面这个例子:

<vbox datasources="http://www.xulplanet.com/ds/sample.rdf"
         ref="http://www.xulplanet.com/rdf/A" hidden="true">
  <template>
    ...
  </template>
</vbox>

这个例子中vbox通过hidden属性隐藏了。此时,模板构建器将不会做任何事情,因为产生了任何结果集也不能被显示,构建器将推迟它的工作。如果你把vbox的隐藏属性去掉,模板构建器会被激活,并产生你想要的结果集。

那这是不是意味着落模板不能用在界面中的隐藏部分呢?不是的,你一样可以使用。将元素的隐藏属性去掉并不是唯一促使构建器产生结果的方法。 Calling a DOM API which needs to get at the generated content will cause the template builder to generate output. For example, just calling the code like the following on the hidden vbox above will start off the template builder.

var length = vbox.childNodes.length;

This request to return the number of children of the vbox will make the template builder process the query and output content. Once done, the correct length can be returned.

All of this is transparent to the XUL developer. When the template builder decides to start generation is determined automatically, and you don't need to do anything special to get this to happen. However, there are two cases where content is not generated automatically: menus and child tree items.

Content inside a menu is not generated until the menu is opened. This makes sense since the user can't see the contents of the menu until it is open. However, it also means that the DOM API usage, such as an attempt to get the number of child nodes as above, will also not include generated items until the menu is opened. This is an important distinction. That means that you will not be able to rely on being able to retrieve the generated menu items until the menu is opened. A similar rule applies for child tree items. The children are not generated until the user presses the twisty to open the container or when a script opens a row.

Lazy generation comes in handy for menus and trees especially when dealing with recursive items. It would be rather time consuming to generate output for every item in a tree, even for those not displayed, so the template builder doesn't do so.

The template builder is even lazier. If the generated content itself contains hidden elements, those child elements will not be generated until necessary. When building content, the builder iterates down the node tree, copying and building only when needed.

Revision Source

<p><strong>上一页<a href="/User_talk:Dongdong" title="User_talk:Dongdong">User_talk:Dongdong</a></strong>                                <strong>下一页</strong><a href="/User_talk:Dongdong/%E4%BA%A7%E7%94%9F%E7%BB%93%E6%9E%9C" title="User_talk:Dongdong/产生结果">User_talk:Dongdong/产生结果</a></p>
<h3 class="editable"><span> Query </span>
<div class="editIcon"><a href="/../../../../en/XUL/Template_Guide/Rule_Compilation#" style="visibility: hidden;" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="../../../../skins/common/icons/icon-trans.gif"></span></a></div>
</h3>
<p>一个XUL模板是由一个查询条件和一系列Rules条件组成的。一个查询条件中包括了关于如何从数据源中取数据的指示。不同的数据源有不同的语法。 例如,如果是SQLite数据源,一个SQL语句就是查询条件。这就能产生一组结果并以此得到最终想要的结果。如果是RDF或XML,查询条件就包括了一 组用于浏览RDF图和DOM结点的指示。查询条件是在query标签中声明的(Firefox3中支持这个语法,Firefox2中只支持RDF数据源并 且没有query这个标签),query标签直接放在template标签内。query是用来产生一组结果集的。</p>
<h3 class="editable"><span> Rules </span>
<div class="editIcon"><a href="/../../../../en/XUL/Template_Guide/Rule_Compilation#" style="visibility: hidden;" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="../../../../skins/common/icons/icon-trans.gif"></span></a></div>
</h3>
<p>模板也包括了一组规则(Rules),用于从不同的条件产生不同的结果。还有在后面我们要谈到的attribute置换语法,用来得到并变更从模板中得到的结果值。规则是用rule标记定义的,你可以定义多个规则。从query得到的结果都会经过规则的过滤,最终得到的数据就是满足规则的数据。需要注意的是,数据找到满足条件的第一个规则后,其它的规则将不再对该数据进行过滤。例如,第一个规则如果过滤书,那么第二个规则就只能对杂志进行过滤。也就是说,数据过滤一个就少一个。按这种方式,不同的数据产生不同的结果。</p>
<p>在很多情况下,你只需要一个规则,因为你想让所有数据按照一个规则过滤。比如,你在产生一个列表框时,只通常只会用一个规则。如果只需要一个规则,可以不定义rule标记。一个没有任何规则的模板会对每个数据进行无条件过滤。</p>
<h3 class="editable"><span> Template语法概要</span>
<div class="editIcon"><a href="/../../../../en/XUL/Template_Guide/Rule_Compilation#" style="visibility: hidden;" title="Edit section"><span class="icon"><img alt="Edit section" class="sectionedit" src="../../../../skins/common/icons/icon-trans.gif"></span></a></div>
</h3>
<p>下面是模板语法概要</p>
<pre>&lt;vbox datasources="http://www.xulplanet.com/ds/sample.rdf"
         ref="http://www.xulplanet.com/rdf/A" flex="1"&gt;
  &lt;template&gt;
    &lt;query&gt;
      -- query content goes here --
    &lt;/query&gt;
    &lt;rule&gt;
      -- rule content goes here --
    &lt;/rule&gt;
    &lt;rule&gt;
      -- rule content goes here --
    &lt;/rule&gt;
  &lt;/template&gt;
&lt;/vbox&gt;
</pre>
<p> </p>
<h3 class="editable"><span> Query/rule 的编译与结果集的惰性产生机制</span><span><br>
</span></h3>
<p>当模板构建器开始处理数据,并在它开始加载数据源后,它必须编译Query和Rule.这个步骤包括分析查询规则并将之转换为内部数据结构。因此,如果动态改变规则将不会有任何效果。然而,通过调用builder.rebuild重构模板时,会对查询规则进行重新编译,并再次应用模板。这就意味着你可以用DOM方法来改变规则,重构模板然后得到新的不同的结果。</p>
<p>一旦模板构建器编译完规则,查询和产生结果集的过程就开始了。模板构建器产生结果集的过程是很懒惰的,它只在需要的时候才进行处理。例如,考虑下面这个例子:</p>
<pre>&lt;vbox datasources="http://www.xulplanet.com/ds/sample.rdf"
         ref="http://www.xulplanet.com/rdf/A" hidden="true"&gt;
  &lt;template&gt;
    ...
  &lt;/template&gt;
&lt;/vbox&gt;
</pre>
<p>这个例子中vbox通过hidden属性隐藏了。此时,模板构建器将不会做任何事情,因为产生了任何结果集也不能被显示,构建器将推迟它的工作。如果你把vbox的隐藏属性去掉,模板构建器会被激活,并产生你想要的结果集。</p>
<p>那这是不是意味着落模板不能用在界面中的隐藏部分呢?不是的,你一样可以使用。将元素的隐藏属性去掉并不是唯一促使构建器产生结果的方法。 Calling a DOM API which needs to get at the generated content will cause the template builder to generate output. For example, just calling the code like the following on the hidden vbox above will start off the template builder.</p>
<pre>var length = vbox.childNodes.length;
</pre>
<p>This request to return the number of children of the vbox will make the template builder process the query and output content. Once done, the correct length can be returned.</p>
<p>All of this is transparent to the XUL developer. When the template builder decides to start generation is determined automatically, and you don't need to do anything special to get this to happen. However, there are two cases where content is not generated automatically: menus and child tree items.</p>
<p>Content inside a menu is not generated until the menu is opened. This makes sense since the user can't see the contents of the menu until it is open. However, it also means that the DOM API usage, such as an attempt to get the number of child nodes as above, will also not include generated items until the menu is opened. This is an important distinction. That means that you will not be able to rely on being able to retrieve the generated menu items until the menu is opened. A similar rule applies for child tree items. The children are not generated until the user presses the twisty to open the container or when a script opens a row.</p>
<p>Lazy generation comes in handy for menus and trees especially when dealing with recursive items. It would be rather time consuming to generate output for every item in a tree, even for those not displayed, so the template builder doesn't do so.</p>
<p>The template builder is even lazier. If the generated content itself contains hidden elements, those child elements will not be generated until necessary. When building content, the builder iterates down the node tree, copying and building only when needed.</p>
Revert to this revision