![]() |
![]() |
![]() |
||||||||||||||
| Chocolate, Vanilla, Caramel < TMQL Introduction < < Home | ||||||||||||||||
|
Chocolate, Vanilla, CaramelThe different language flavours, select and path expressions, can―as we have already seen― be mixed. Not so obvious is the fact that both styles are (almost) equivalent in terms of expressitivity; every select query expression can in fact be transformed into an equivalent path expression. As path expressions cannot introduce new variables, they can become quite contrived when they get more complex.It is up to the developer to choose the most appropriate combination on a case by case basis. Both these styles allow to return sequences of tuples of things into the application. This may be exactly along your line of thinking in most cases, but it does not help tremendously if you want to comfortably embed the query results into one of these shiny XML applications servers. To avoid that developers have to write their own template engines, TMQL allows to create XML content using a third flavour, which―you may have guessed it―is otherwise equivalent to the other styles. This flavour, FLWR, is inspired by XQuery and uses RETURN clauses to specify the output:
return
<albums>{
for $a in // album return
<album>{$a / name [@ en ]}</album>
}
</albums>
The return value here will create one XML 'document' as data structure (implementations will
probably choose DOM for that) with a root element <albums>. Nested into
that will be all albums in the map. The way this is achieved is by iterating over albums in a
FOR loop. It uses a path expression // album to compute first all
instances of albums in our map. Each such album is bound to the iteration variable
$a and with such a new binding, the body of the loop is evaluated.
Such body is defined by a nested RETURN clause. It contains an element <album> which wraps only text content which we specify with an embedded TMQL path expression $a / name [@ en ]. Like in XQuery, XML content and query text is separated using {} brackets. Since the processor knows that here text has to be, it will implicitly take the string value of that basename.
|
|||||||||||||||