In my current project using JET I am finding that I use the same
expressions over and over again throughout numerous files. Some of these
expressions are quite long. In order to increase maintainability of my
templates, I require a way to store an XPath expression as a global
variable. Clearly, c:setVariable is what I need. However, I'm running into
a couple of issues...

could work, however, this expression is declared right at the top of my
main.jet. Consequently, the variable $entityName does not yet exist (it is
assigned later on when processing elements). When $entityName does not
exist, not only are errors thrown but the variable $allEntityAttributes is
not assigned any value and as a result cannot be used.

Are there any ways to achieve the functionality I require? I simply want
to store an XPath expression string (which itself includes variables) as a
variable so it can be reused many times.

try it with the default string('xyz') function of the XPath 1.0 spec. I
don't know whether this works, but it might be another possibility.

Timothy

Mark Wood schrieb:
> Hello,
>
> This post is a sort of follow on from:
>
> http://dev.eclipse.org/newslists/news.eclipse.modeling.m2t/m sg00706.html
>
> In my current project using JET I am finding that I use the same
> expressions over and over again throughout numerous files. Some of these
> expressions are quite long. In order to increase maintainability of my
> templates, I require a way to store an XPath expression as a global
> variable. Clearly, c:setVariable is what I need. However, I'm running
> into a couple of issues...
>
> In my main.jet file, I would like to declare the following variable:
>
> <c:setVariable var="allEntityAttributes"
> select=" //namedElements[self::Entity][@name='{$entityName}']/feature s[self::Attribute] "
> />
>
> The issues are as follows:
>
> - The select expression is evaluated as an XPath expression because of
> the nature of setVariable, however I just want to store the actual
> string it represents.
>
> Adding spaces in this way:
> select="
> //namedElements[self::Entity][@name='{$entityName}']/feature s[self::Attribute]
> "
>
> could work, however, this expression is declared right at the top of my
> main.jet. Consequently, the variable $entityName does not yet exist (it
> is assigned later on when processing elements). When $entityName does
> not exist, not only are errors thrown but the variable
> $allEntityAttributes is not assigned any value and as a result cannot be
> used.
>
> Are there any ways to achieve the functionality I require? I simply want
> to store an XPath expression string (which itself includes variables) as
> a variable so it can be reused many times.
>
> Thanks,
>
> Mark
>

Unfortunately the string() function doesn't make any difference -- I get
the same results.

I think it's due to how the variable $entityName is used:

'{$entityName}'

I think maybe the presence of the curly brackets is causing the expression
to be evaluated regardless (just a guess). Obviously though if I remove
the brackets then the expression will be selecting entities which have the
name "$entityName". Clearly this is not what I want.

Out of the box, JET doesn't have a way to dynamically evaluate an XPath
expression stored as a string. But, I've crafted an XPath function that can
do it.

You then have two steps:
1) store your XPath expression as a string:
2) use the custom Xpath function to evaluate it:

Storing your XPath expression as a string
-----------------------------------------
You want to store the unevaluated XPath expression, so, use a String
expression - that is, surround the expression in quotes. Of course, you are
using quotes in the expression, and the attribute itself is using quotes, so
you need to do a little escaping (this works in JET 0.9 and later). Here's
your expression, respun:

Many thanks for getting back to me. I had a quick play with your first
suggested solution and that was successful. I will switch over to using
the function later.

I'd certainly vote for this being added to JET permanently. It facilitates
easier to read, more manageable code; particularly if the model you are
generating from changes significantly -- going through all of the
templates and having to change each expression is a real pain.