Trevor Nash wrote:
> I would like this kind of thing to work:
>
> content: combo-box(attribute, idref, values, xpath("//account/@id") )
>
> i.e. to present a list of id values possibly restricted to a particular
> element type for the purpose of setting the value of a cross-reference
> attribute.
>
> Currently the result of the xpath gets converted to a string which means
> you only get the value of the first node.
--> This should work fine:
content: combo-box(attribute, idref,
values, xpath("join(//account/@id, '\A')") );
The join() XPath extension function is documented here:
http://www.xmlmind.com/xmleditor/_distrib/doc/commands/xpathextfunc.html
The problem with the above combo-box is that the "values" argument is
evaluated just once when the element which is the target of the CSS rule
is created.
That is, adding IDs to your document does not update the combo-box.
--> This problem is solved by using another approach:
[1] Add a macro look like this to your configuration file:
<command name="pickId">
<macro>
<sequence>
<get expression="join(//para/@id, ' ')" />
<command name="pick" parameter="'Pick an ID' false %_" />
<command name="putAttribute" parameter="linkend %_" />
</sequence>
</macro>
</command>
[2] Style the link element with a rule looking like this:
link:after {
content: command-button(icon, icon(right), command, "pickId");
color: rgb(128,128,196);
}
> Possible approaches, in order of preference (based on usefullness for
> doing other things):
> 1. Extend the type system used in the CSS code and combo-box etc to
> understand node sets
> 2. Implement XPath 2.0 which would allow the required \A separated
> string to be constructed
> 3. Somehow mark a target element and then have a command which inserts
> the ID value from a previously marked element (not far away from the
> copy & paste that I am currently doing).
>
> I know about the ID picker in the attribute editor but my document type
> has *lots* of elements with IDs on - it really needs to be filtered by
> element type to be useful. It would also be useful to be able to have
> labels other than the actual ID value.
>
> I also know I could probably construct this by hacking some Java, but it
> seems to me this should be a more generic feature. Maybe somebody has
> already written such a beast, or would contribute towards me doing so?
>
The ID picker in the Attributes Tool is useful in its current state
(here, at XMLmind, we use it all the time), but it requires that you
give your elements somewhat long and descriptive IDs.