Java Reference
In-Depth Information
As you can see, this is a much nicer use of polymorphism, although our
obligatory
«DEFINE»
for the
MapElement
still exists. If you're curious, consider
this portion of the workflow file that sets up the outlets and invokes this
template:
<outlet path="${out}"/>
<outlet name="RELATIONS_OUTLET" path="out" append="true"/>
<outlet name="TOPIC_OUTLET" path="out" append="true"/>
<expand value="mindmap2csv::Main FOR model"/>
14.1.4 FILE
The previous sections have already covered most of how
«FILE»
works, so if
you've skipped to this section, you might want to go back and read up the
EXPAND
topic. This is the syntax for
«FILE»
:
«
FILE
expression [OUTLET_NAME]»
. . .
«
ENDFILE
»
As you've seen, you can possibly combine strings and model element values
using
+
to form the
«FILE»
name, or expression. A previous example used the
title
of the
Map
element combined with the string
-topics.csv
.
OUTLET_NAME
is optional and corresponds to a named
<outlet/>
element
defined in a workflow file. One way to think about this is to consider the use of
outlets as named streams. In fact, future versions of Xpand might provide more
formal support for the named stream concept. The GMF version of Xpand relies
on the stream concept because the output files used for persistence are deter-
mined externally in Java code. This feature should become available in M2T
Xpand in the future, where file output likely will be specified within the work-
flow instead of within the Xpand template itself.
14.1.5 FOREACH
When working with collection types, it is often necessary to iterate through their
contents. You've already seen
FOREACH
used within an
EXPAND
statement for this
purpose. However, frequently iteration is required within
«DEFINE»
blocks,
which is where
«FOREACH»
comes into play.
Search WWH ::
Custom Search