Dynamic properties in sort

Hi,

I believe, and maybe Sara can confirm this for us, that you can only use Template variables where you would normally be able to use a valid XPath expression. Since "sortdir" is a string value of either "ascending" or "descending", I wouldn't expect a Template expression to work here.

However, I tried to use a template expression to specify the sort key for the "sortkeys" attribute but did not get it to work either. This seems to be a bug. Can anyone confirm this?

I also noticed that when the template expression is evaluated, the space between the two variable substitution statements is removed, effectively concatenating the two values. So expr="{$fldName} {$direction}" results in "*:titledescending". Note: there is a leading space inserted in the "direction" variable default value in the attached code example to prevent this happening.

You can append "ascending" or "descending" to the end of a sort key value (e.g. sortkeys="*:title descending") to specify the direction of the sort, which means you don't need to use the "sortdir" attribute if you don't want to. You can also have mixed sort key directions (e.g sortkeys="*:onefield descending, *:anotherfield ascending").

Here's my test emml code used to test this issue:

	<operation name="runTest21">

		<output name="testOutput" type="document"></output>

		<variables>
			<variable name="data" type="document" />
			<variable name="sortparms" type="string" />
			<variable name="testparms" type="string" />
			<variable name="direction" type="string" default=" descending" />
			<variable name="fldName" type="string" default="title" />
		</variables>

		<constructor outputvariable="data">
			<feed>
				<entry>
					<title>1</title>
					<field1>a</field1>
					<field2>x</field2>
				</entry>
				<entry>
					<title>2</title>
					<field1>b</field1>
					<field2>y</field2>
				</entry>
				<entry>
					<title>3</title>
					<field1>c</field1>
					<field2>z</field2>
				</entry>
			</feed>
		</constructor>

		<display message="fldName=" variable="fldName" />
		<template expr="{$fldName} {$direction}" outputvariable="sortparms" />
		<display message="sortparms=" expr="$sortparms" />
		
		<sort inputvariable="data" sortkeys="$sortparms"
			sortexpr="/*:feed/*:entry" outputvariable="testOutput" />

	</operation>

and this results in:

fldName=    title 
sortparms=    title descending 

<?xml version="1.0" encoding="UTF-8"?>
<feed>
   <entry>
      <title>1</title>
      <field1>a</field1>
      <field2>x</field2>
   </entry>
   <entry>
      <title>2</title>
      <field1>b</field1>
      <field2>y</field2>
   </entry>
   <entry>
      <title>3</title>
      <field1>c</field1>
      <field2>z</field2>
   </entry>
</feed>

Cheers, Innes

Hi,

I take that back ... the bit about only being able to use <template> variables where an XPath expression would normally be used.

I've just proved my theory wrong by using a template variable in an <sql /> datasource attribute definition.

Ok, so what are the rules for using these and why didn't the above sortdir or sortkeys work? Any one?

Cheers, Innes

The answer is, unfortunately, that there isn't a 'rule' to where you can use <template> or parameterize an attribute in EMML statements. This has to be implemented in the software and it isn't implemented -- or documented -- in all cases.

I'm going to do some testing with <sort> -- so more information will be available a little later.

<!--Session data-->

Thanks Sara,

Might be an interesting task for some "down time" ... map the emml statements and attributes and their acceptance of <template> constructed values.

Cheers, Innes

Down time? is that a foreign language?

I've done a little more testing and am now confused about how I came up with the sample that is in the docs. The results are clear in some cases and not so clear in others.

Based on my tests, it is clear that @sortexpr and @sortdir *cannot* use parameter references, much less anything doubly-parameterized in <template>. @sortkey should also be considered as not accepting parameters since the behavior is not consistent.

And I will add this to my list of things to clean up in the documentation, with apologies to all who were misled.

<!--Session data-->

<!--Session data-->

Hey Sara,

I think it comes sometime between midnight and about 6am ... lol ... and I wasn't thinking of you specifically. I know how busy you guys with other things at the moment. I'm sure we could collaborativelly map out the attributes that accept <template> parametisation.

Cheers, Innes

Well, I would welcome input from the community. The more the merrier!

<!--Session data-->