dynamiclist.dtd: Elements - Entities - Source | Intro - Index
FRAMES / NO FRAMES
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- The XML defined after this document describes which query to make and how to display its results. The query is defined under the query tag. Here is an example : % <query repository="\%\bbackgrounder" numberitems="3"> <filter type="includes" tagName="usertype"> <parameter>guest</parameter> </filter> <sort order="ascending" tagName="harvestdate"/> </query> % One reads it this way : <blockquote> The query will be made upon the backgrounder repository. Therefore, the query will give some backgrounders as a result. The result set will contain at most 3 backgrounders, sorted upon their harvest date, in a ascending order. The selected backgrounders are those of which the usertype tag includes the gues value. </blockquote> It is a rather straightforward explanation. Basically, the query works as a filter. All the content items of the given repository for the current site are filtered out according to the "filter" tag. The type of the filter indicates what to check for. Usually filter should always work list is intended for the homepage, this component won't be able to display complex content or big content. It is rather intended to display a few information taken out of each of the items returned by the query. Let's look at an example. % <display template="template2"> <map tagName="title" holeName="a"/> <map tagName="harvestdate" holeName="b"/> </display> % One reads it this way : <blockquote> Each of the item will be displayed according to the template "template2". Once displayed, the holes in the template will be replaced by values taken from the items returned by the query. </blockquote> Before rereading the explaination, here are the different standard templates : ... So as said above, the templates will be used to display each item. @title Dynamic List Box @hidden somethings should never be told. But everybody should know them. @root dynamiclist --> <!-- Dynamic list top node. --> <!ELEMENT dynamiclist (version, country+, language, author, itemname, site+, topic*, source, usertype+, publishdate, harvestdate, title, abstract, query, display)> <!-- Names of the content tags recognized by the system. The recognized tags are those declared by the item descriptors. Of course, some tags are recognized for some (and only some) content, making this list erroneous. But this validation is still better than nothing (it validates syntax, not semantic). --> <!ENTITY % recognizedContentTag "(title | topic | harvestdate | usertype)"> <!-- The query part describes how to retrieve the results from the repository to display. We could have made it closer to the targeter definition but then it'd be too complicated for an end user. However, as functionality will be extended, it'd be nice to keep in mind that getting closer to Dynamo's way of describing queries will make the transformation of this XML into 'real' queries easier. --> <!ELEMENT query (filter, sort)> <!-- @attr @attr aaaa @attr repository The repository on which to apply the query. It is an attribute so that we get instant validation through DTD. As a naming convention, the repository name is the one of the corresponding RepositoryName property of the repository. So for example for the backgrounders, we'll use the name "BackgroundersRepository" because the repository property defined in /configurations/common/repositories/backgrounders/BackgroundersRepository.properties is such. This will allow to build a automatic (configuration-less) mapper. @attr numberitems The maximum number of items returned by the query to display. --> <!ATTLIST query repository (backgrounder) #REQUIRED numberitems (1 | 2 | 3 | 4 | 5) "1" > <!-- The filter describes which items to retrieve from the repository. Basically, it states a condition that each item must satisfy to be part of the result set. A filter might need several parameters. --> <!ELEMENT filter (parameter)> <!-- A parameter to the filter. For example a filter can ask to get elements belonging to a list.--> <!ELEMENT parameter (#PCDATA)> <!ATTLIST filter type (includes | equals) #REQUIRED tagName %recognizedContentTag; #REQUIRED > <!-- Tells on which tag to sort the content. Please note that the tag must be reachable by Dynamo as a property. Therefore, its definition must appear in the "itemdescriptors". Please note that it doesn't make sense to sort on multi-valued tags. The sort information have been put in a separate element to allow for a sort on several tags (we could have given all the tags in a coma separated list but then we would have lost the DTD validation capabilities. --> <!ELEMENT sort EMPTY> <!-- Tells in which order to sort. --> <!ATTLIST sort order (ascending | descending) "ascending"> <!-- Tells on which item's tag to sort. --> <!ATTLIST sort tagName %recognizedContentTag; #REQUIRED> <!-- The display tag describes how each item will rendered. Right now, the items are assumed to be displayed one below each other. --> <!ELEMENT display (map+)> <!-- Selects which template to be used for the display. Several are available. --> <!ATTLIST display template ( template1 | template2 | template3 | template4) "template1" > <!-- Each template has holes to be filled, named a,b,c,... The map tags tell what value to put in each hole. This tag is only defined by attributes right now. --> <!ELEMENT map EMPTY> <!-- The name of the tag of which the value must be put in a given hole. --> <!ATTLIST map tagName %recognizedContentTag; #REQUIRED > <!-- The name of the hole to fill in the template. --> <!ATTLIST map holeName (a | b | c) #REQUIRED fun1 NMTOKEN #REQUIRED fun2 IDREF #REQUIRED > <!ELEMENT alpha (#PCDATA)> <!ELEMENT beta (alpha,alpha)+> <!ELEMENT gamma (beta,beta)+> <!ELEMENT zeta EMPTY> <!ELEMENT rho ANY> <!ELEMENT phi (beta,beta,beta,(beta|beta))+> <!ELEMENT ksi (#PCDATA|zeta|rho)*> <!ENTITY % common_cms SYSTEM "common/common_cms.dtd"> %common_cms;