Automatically creating ids with setValue or generate-id()

My XForms instance data has a fairly large amount of attributes typed  
as xsd:ID, which means that they are required elements.  As a  
convenience I would like to populate these fields, using the XSL  
function generate-id(), but I'm running into some trouble.  Below is  
what I tried, but it doesn't work:

<xforms:input ref="@ID" xhtml:size="30">
    <xforms:setValue ref="@ID"><xsl:value-of select="generate-id(.)"/
 ></xforms:setValue>
    <xforms:label class="fixed-width">ID: </xforms:label>
</xforms:input>

Also, I tried to do this via XSL with my document as a result of a  
copy-of statement, but it also didn't work:

<xsl:copy-of select="doc('input:instance')/*/(document-id | document)"/>
  <xsl:for-each select="//@ID">
    <xsl:attribute name="ID">
      <xsl:value-of select="generate-id(.)"/>
     </xsl:attribute>
   </xsl:for-each>

I suspect that my XSL is flawed, but it is the preferable way to  
address each ID attribute in the whole form.  Has anyone else done  
something similar to this?



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

How is the problem manifested?

On Dec 10, 2005, at 10:07 PM, Duane Gran wrote:



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Basically nothing happens.  In the case of setValue, the ID attribute  
in question remains blank (the initial value).  In the case of my XSL  
approach, the ID again remains blank, but in this case I believe my  
error is in faulty XSL.  Unfortunately it is quite hard to debug the  
xpath statements and whatnot since the instance document is  
constructed via a pipeline.

Getting to the issue of setValue, my reading of the XForms spec  
doesn't imply that it only activates within a trigger.  Is this a  
case of a bug in OPS or is the spec ambiguous on this point?

Duane

On Dec 12, 2005, at 8:11 AM, [hidden email] wrote:



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Duane,
       

1. <xforms:setValue> should be <xforms:setvalue>
2. I'm sure you will have to add an event to the <xforms:setvalue> to work
within the input
3. XSL is only run once one the xforms page, if this needed to run more that
once i.e. every time you changed the input it wouldn't do that. So that
said I don't think you will be able to use the XSL function.

Ryan Puddephatt
Web Developer
TFX Group
1 Michaelson Square
Livingston
West Lothian
Scotand
EH54 7DP
 
* [hidden email]
( 01506 407 110
7  01506 407 108
 

-----Original Message-----
From: Duane Gran [mailto:[hidden email]]
Sent: 12 December 2005 13:58
To: [hidden email]
Subject: Re: [ops-users] Automatically creating ids with setValue or
generate-id()

Basically nothing happens.  In the case of setValue, the ID attribute  
in question remains blank (the initial value).  In the case of my XSL  
approach, the ID again remains blank, but in this case I believe my  
error is in faulty XSL.  Unfortunately it is quite hard to debug the  
xpath statements and whatnot since the instance document is  
constructed via a pipeline.

Getting to the issue of setValue, my reading of the XForms spec  
doesn't imply that it only activates within a trigger.  Is this a  
case of a bug in OPS or is the spec ambiguous on this point?

Duane

On Dec 12, 2005, at 8:11 AM, [hidden email] wrote:





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

You can copy the dynamically generated instance XML from the console
(or whatever you are using to look at the debug code), paste into your
XML editor and create a test XSL (or copy it from your XSLT processor)
to mimic what your XSLT processor does. This is great for testing as
you can more quickly fine-tune and debug your transformation templates.
  These days, every good XML editor seems to have also "XPath" field
where you can enter arbitrary XPath expression and run it against an
XML document. I am using Oxygen which allows you to do this.

A.

On Dec 12, 2005, at 8:58 AM, Duane Gran wrote:



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Duane Gran wrote:
 > My XForms instance data has a fairly large amount of attributes typed
 > as xsd:ID, which means that they are required elements.  As a
 > convenience I would like to populate these fields, using the XSL
 > function generate-id(), but I'm running into some trouble.  Below is
 > what I tried, but it doesn't work:
 >
 > <xforms:input ref="@ID" xhtml:size="30">
 >    <xforms:setValue ref="@ID"><xsl:value-of select="generate-id(.)"/
 >  ></xforms:setValue>
 >    <xforms:label class="fixed-width">ID: </xforms:label>
 > </xforms:input>

There are many issues in the above code (some of which Ryan has just
noted as well):

1. An XForms action must have an "ev:event" attribute to be
    triggered. Within an xforms:input, the action is usually
    "xforms-value-changed" or "DOMActivate".

2. "xforms:setValue" is not an action name, the correct name is
    "xforms:setvalue" (but that's probably just a typo in your email).

3. "ref" attributes are relative to enclosing elements with "ref" or
    "nodeset" attributes. If your xforms:input field points to "@ID",
    your nested "xforms:setvalue" element cannot have a relative "@ID"
    attribute: this simply doesn't make sense in XPath, as attributes
    nodes don't have children attribute nodes.

Even if you fix the code above, what you will achieve will be an input
field that will allow you to enter text, which will do nothing but
from time to time cause a constant value (the id generated by XSLT) to
be stored into the instance. If nobody ever touches that input field,
the id will not even make it into the instance.

If the structure of your XForms instance is static (only its values do
change), then you can dynamically generate your XForms instance with
XSLT's generate-id(). This can be done with an XSLT page view.

If the structure changes (elements added or removed with
xforms:repeat), you probably still need to generate an initial XForms
instance with constant ids, then be a little smarter upon
xforms:repeat insertion to add suffixes to those ids so that they are
unique.

 > Also, I tried to do this via XSL with my document as a result of a
 > copy-of statement, but it also didn't work:
 >
 > <xsl:copy-of select="doc('input:instance')/*/(document-id | document)"/>
 >  <xsl:for-each select="//@ID">
 >    <xsl:attribute name="ID">
 >      <xsl:value-of select="generate-id(.)"/>
 >     </xsl:attribute>
 >   </xsl:for-each>
 >
 > I suspect that my XSL is flawed

Yes. This will cause your XSLT to try creating on the current element
as many "@ID" attributes as there are "@ID" attributes in your
original document, which should fail, because only one "@ID" attribute
is allowed on an element.

 > but it is the preferable way to address each ID attribute in the
 > whole form.  Has anyone else done something similar to this?

I can see solutions. Actually generating the ids entirely in XForms
could be possible by using something like:

<xforms:bind nodeset="//@ID" calculate="generate-id()"/>

however, the generate-id() function is not supported by XForms 1.0: it
is an XSLT function. In fact it almost worked in OPS (I had to fix a
little detail to make it work), but it won't be a portable solution.

I think, as noted above, that the most portable solution consists in
using XSLT to generate ids in the initial instance, and then use
xforms:setvalue upon xforms:insert to assign new ids to newly inserted
elements.

-Erik





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws