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;