Setting values of elements in a repeat

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Setting values of elements in a repeat

David McIntyre
I'm working on an application allows users to obtain values from an external webpage to fill in a form.  The idea is that they can click on a link which pops up a new window for the user to search for the value they want, and the new window uses JavaScript to communicate the value chosen back to the original page.  Next, I have to be able to use JavaScript to get that value into the XForm.

As documented in http://www.orbeon.com/ops/doc/reference-xforms-ng#d1615550e4670 , this is possible by using
	var control = document.getElementById('myControl');
	control.value = valueToSet;
So far so good.  However, I've been trying to reproduce the behaviour in the case where the control I want to set the value of is in a repeat, and it does not seem to behave in the same way. 

Looking at the HTML source of the page that is created, I see that the document.getElementById() actually returns a <span> element which contains the <input> element, so there must be some extra work going on to set the value in the <input> element and then update the model state.  However, this behaviour does not seem to work with nodes within a repeat -- instead I have had to find the appropriate child of the <span> element, set its value, and then manually fire an onchange event. 

Any thoughts?

Cheers,
    Dave McIntyre

--
Orion Signature
Dave McIntyre
Software Developer
2nd Floor, Orion House, cnr Enfield & Mary St, Mt Eden, PO Box 8273, Auckland, New Zealand
M.+64 21 212 8087 P.+64 9 638 0600 F.+64 9 638 0699
S.<a href="callto:dave.mcintyre">dave.mcintyre E.[hidden email] W.www.orionhealth.com




This e-mail and any attachments are intended only for the person to whom it is addressed and may contain privileged, proprietary, or other data protected from disclosure under applicable law. If you are not the addressee or the person responsible for delivering this to the addressee you are hereby notified that reading, copying or distributing this transmission is prohibited. If you have received this e-mail in error, please telephone us immediately and remove all copies of it from your system. Thank you for your co-operation.


--
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
Reply | Threaded
Open this post in threaded view
|

Re: Setting values of elements in a repeat

Erik Bruchez
Administrator
Dave,

 > I'm working on an application allows users to obtain values from an
 > external webpage to fill in a form.  The idea is that they can click
 > on a link which pops up a new window for the user to search for the
 > value they want, and the new window uses JavaScript to communicate
 > the value chosen back to the original page.

Ouch, one of those ;-)

 > Next, I have to be able to use JavaScript to get that value into the
 > XForm.
 >
 > As documented in
 > http://www.orbeon.com/ops/doc/reference-xforms-ng#d1615550e4670 , this
 > is possible by using
 >
 > |var control = document.getElementById('myControl');
 > control.value = valueToSet;
 > |
 >
 > So far so good.  However, I've been trying to reproduce the behaviour in
 > the case where the control I want to set the value of is in a repeat,
 > and it does not seem to behave in the same way.

This is because XForms controls have unique ids in your source
document, but as they are used in a repeat in the client, we give them
so-called "effective ids", of the form "myid.1", "myid.2", etc. This
is necessary because ids in a document (here an HTML or XHTML
document) must be unique.

 > Looking at the HTML source of the page that is created, I see that
 > the document.getElementById() actually returns a <span> element
 > which contains the <input> element

Most likely you are obtaining a reference to the template for the
repeat. The <span> is normal in any case, whether you obtain a repeat
template or a control, as we encapsulate most controls within <span>
elements.

 > so there must be some extra work going on to set the value in the
 > <input> element and then update the model state.

Yes, our JavaScript code intercepts access to .value on the span, and
does the magic in the background. You should not expect that an
xforms:input will just produce an HTML input element and nothing else,
so this mechanism provides the flexibility of changing the underlying
HTML implementation while keeping the JavaScript code compatible.

 > However, this behaviour does not seem to work with nodes within a
 > repeat -- instead I have had to find the appropriate child of the
 > <span> element, set its value, and then manually fire an onchange
 > event.

This is a bug, or rather a missing feature. I have entered an RFE to
track this:

 
http://forge.objectweb.org/tracker/index.php?func=detail&aid=305806&group_id=168&atid=350207

But you have a solution that's working for now, right?

-Erik

--
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/



--
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
Reply | Threaded
Open this post in threaded view
|

Re: Setting values of elements in a repeat

David McIntyre
Thanks for your response.  Yes, I've found an workaround for now, but it does rely on the structure of the processed document so I would only regard it as a temporary fix.  There are actually a couple of issues that I have found:
* as you have noted, the getElementById().value method doesn't work with elements in a repeat
* there appears to be a problem with the way that "myid" gets replaced by "myid.1", "myid.2" etc, so that the id on an <a> tag doesn't get the suffix in the same way that other elements do, for repeats that are already present in the form when it is constructed (and, naturally enough, it was the id of the <a> tag that I was going to pass to the javascript function call ...).  This problem doesn't show up for repeats which are added dynamically to the form. 

I'm afraid I only have a relatively complex example of this in action - I'll trim it down to a small example to post to the list as soon as I can.

Cheers,
    Dave McIntyre

Erik Bruchez wrote:
Dave,

> I'm working on an application allows users to obtain values from an
> external webpage to fill in a form.  The idea is that they can click
> on a link which pops up a new window for the user to search for the
> value they want, and the new window uses JavaScript to communicate
> the value chosen back to the original page.

Ouch, one of those ;-)

> Next, I have to be able to use JavaScript to get that value into the
> XForm.
>
> As documented in
> http://www.orbeon.com/ops/doc/reference-xforms-ng#d1615550e4670 , this
> is possible by using
>
>     |var control = document.getElementById('myControl');
>     control.value = valueToSet;
> |
>
> So far so good.  However, I've been trying to reproduce the behaviour in
> the case where the control I want to set the value of is in a repeat,
> and it does not seem to behave in the same way.

This is because XForms controls have unique ids in your source
document, but as they are used in a repeat in the client, we give them
so-called "effective ids", of the form "myid.1", "myid.2", etc. This
is necessary because ids in a document (here an HTML or XHTML
document) must be unique.

> Looking at the HTML source of the page that is created, I see that
> the document.getElementById() actually returns a <span> element
> which contains the <input> element

Most likely you are obtaining a reference to the template for the
repeat. The <span> is normal in any case, whether you obtain a repeat
template or a control, as we encapsulate most controls within <span>
elements.

> so there must be some extra work going on to set the value in the
> <input> element and then update the model state.

Yes, our JavaScript code intercepts access to .value on the span, and
does the magic in the background. You should not expect that an
xforms:input will just produce an HTML input element and nothing else,
so this mechanism provides the flexibility of changing the underlying
HTML implementation while keeping the JavaScript code compatible.

> However, this behaviour does not seem to work with nodes within a
> repeat -- instead I have had to find the appropriate child of the
> <span> element, set its value, and then manually fire an onchange
> event.

This is a bug, or rather a missing feature. I have entered an RFE to
track this:


http://forge.objectweb.org/tracker/index.php?func=detail&aid=305806&group_id=168&atid=350207

But you have a solution that's working for now, right?

-Erik


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


--
Orion Signature
Dave McIntyre
Software Developer
2nd Floor, Orion House, cnr Enfield & Mary St, Mt Eden, PO Box 8273, Auckland, New Zealand
M.+64 21 212 8087 P.+64 9 638 0600 F.+64 9 638 0699
S.<a href="callto:dave.mcintyre">dave.mcintyre E.[hidden email] W.www.orionhealth.com




This e-mail and any attachments are intended only for the person to whom it is addressed and may contain privileged, proprietary, or other data protected from disclosure under applicable law. If you are not the addressee or the person responsible for delivering this to the addressee you are hereby notified that reading, copying or distributing this transmission is prohibited. If you have received this e-mail in error, please telephone us immediately and remove all copies of it from your system. Thank you for your co-operation.


--
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
Reply | Threaded
Open this post in threaded view
|

Re: Setting values of elements in a repeat

David McIntyre
In reply to this post by Erik Bruchez
Sorry I didn't get back on this one sooner.

I've noticed a small problem with the way that anchors in a repeat get effective ids.  I have a repeat which looks like this:
<xforms:repeat bind="bind-things" id="repeat-things">
  <xforms:input ref="." id="input-thing">
    <xforms:label>Thing</xforms:label>
  </xforms:input>
  <xhtml:a href="#" id="anchor">Click Me</xhtml:a>
  <xhtml:br/>
</xforms:repeat>
This gets rendered as
<label id="repeat-begin-repeat-things" class="xforms-repeat-begin-end"></label>
<label class="xforms-repeat-delimiter"></label>
<label for="input-thing·1" class="xforms-label xforms-repeat-selected-item-1">Thing</label>
<span id="input-thing·1" class="xforms-control xforms-input xforms-type-string xforms-repeat-selected-item-1">
	<span class="xforms-date-display"></span>
	<input id="input-input-thing·1" type="text" name="input-thing·1" value="one" class="xforms-input-input  xforms-type-string">
	<span class="xforms-showcalendar" id="showcalendar-input-thing·1"></span>
	<input class="xforms-input-time" value="">
</span>
<a href="#" id="anchor" onclick="alert(this.id)" class="xforms-repeat-selected-item-1">Click Me</a>
<br class="xforms-repeat-selected-item-1">
<label class="xforms-repeat-delimiter"></label>
<label for="input-thing·2" class="xforms-label">Thing</label>
<span id="input-thing·2" class="xforms-control xforms-input xforms-type-string">
	<span class="xforms-date-display"></span>
	<input id="input-input-thing·2" type="text" name="input-thing·2" value="two" class="xforms-input-input  xforms-type-string">
	<span class="xforms-showcalendar" id="showcalendar-input-thing·2"></span>
	<input class="xforms-input-time" value="">
</span>
<a href="#" id="anchor" onclick="alert(this.id)">Click Me</a>
<br>
<label class="xforms-repeat-delimiter"></label>
<label for="input-thing" class="xforms-label xforms-disabled xforms-repeat-template"></label>
<span id="input-thing" class="xforms-control xforms-input xforms-repeat-template">
	<span class="xforms-date-display"></span>
	<input id="input-input-thing" type="text" name="input-thing" value="" class="xforms-input-input">
	<span class="xforms-showcalendar" id="showcalendar-input-thing"></span>
	<input class="xforms-input-time" value="">
</span>
<a href="#" id="anchor" onclick="alert(this.id)" class="xforms-repeat-template">Click Me</a>
<br class="xforms-repeat-template">
<label id="repeat-end-repeat-things" class="xforms-repeat-begin-end"></label>
In other words, although the other elements within the repeat get an effective id of the form originalid.1, originalid.2 and so on within each repeat, the anchor gets the id "anchor" in each row.

Using the onclick alert I can tell that new anchors which are inserted using an <xforms:insert> do get an effective id with the repeat-number appended; it is just the repeats which correspond to items which were already in the instance data at the time the form was rendered that have the problem.

Cheers,
    Dave McIntyre

Erik Bruchez wrote:
Dave,

> I'm working on an application allows users to obtain values from an
> external webpage to fill in a form.  The idea is that they can click
> on a link which pops up a new window for the user to search for the
> value they want, and the new window uses JavaScript to communicate
> the value chosen back to the original page.

Ouch, one of those ;-)

> Next, I have to be able to use JavaScript to get that value into the
> XForm.
>
> As documented in
> http://www.orbeon.com/ops/doc/reference-xforms-ng#d1615550e4670 , this
> is possible by using
>
>     |var control = document.getElementById('myControl');
>     control.value = valueToSet;
> |
>
> So far so good.  However, I've been trying to reproduce the behaviour in
> the case where the control I want to set the value of is in a repeat,
> and it does not seem to behave in the same way.

This is because XForms controls have unique ids in your source
document, but as they are used in a repeat in the client, we give them
so-called "effective ids", of the form "myid.1", "myid.2", etc. This
is necessary because ids in a document (here an HTML or XHTML
document) must be unique.

> Looking at the HTML source of the page that is created, I see that
> the document.getElementById() actually returns a <span> element
> which contains the <input> element

Most likely you are obtaining a reference to the template for the
repeat. The <span> is normal in any case, whether you obtain a repeat
template or a control, as we encapsulate most controls within <span>
elements.

> so there must be some extra work going on to set the value in the
> <input> element and then update the model state.

Yes, our JavaScript code intercepts access to .value on the span, and
does the magic in the background. You should not expect that an
xforms:input will just produce an HTML input element and nothing else,
so this mechanism provides the flexibility of changing the underlying
HTML implementation while keeping the JavaScript code compatible.

> However, this behaviour does not seem to work with nodes within a
> repeat -- instead I have had to find the appropriate child of the
> <span> element, set its value, and then manually fire an onchange
> event.

This is a bug, or rather a missing feature. I have entered an RFE to
track this:


http://forge.objectweb.org/tracker/index.php?func=detail&aid=305806&group_id=168&atid=350207

But you have a solution that's working for now, right?

-Erik


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


--
Orion Signature
Dave McIntyre
Software Developer
2nd Floor, Orion House, cnr Enfield & Mary St, Mt Eden, PO Box 8273, Auckland, New Zealand
M.+64 21 212 8087 P.+64 9 638 0600 F.+64 9 638 0699
S.<a href="callto:dave.mcintyre">dave.mcintyre E.[hidden email] W.www.orionhealth.com




This e-mail and any attachments are intended only for the person to whom it is addressed and may contain privileged, proprietary, or other data protected from disclosure under applicable law. If you are not the addressee or the person responsible for delivering this to the addressee you are hereby notified that reading, copying or distributing this transmission is prohibited. If you have received this e-mail in error, please telephone us immediately and remove all copies of it from your system. Thank you for your co-operation.


--
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
Reply | Threaded
Open this post in threaded view
|

Re: Setting values of elements in a repeat

Alessandro  Vernet
Administrator
Hi Dave,

You are right, when we unroll the repeat, we add a suffix to the ids
of the XForms elements, but we don't do the same for HTML elements. I
created a bug for this:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=305939&group_id=168&atid=350207

Is this causing a problem for your application?

Alex

On 8/9/06, Dave McIntyre <[hidden email]> wrote:

>
>
>  Sorry I didn't get back on this one sooner.
>
>  I've noticed a small problem with the way that anchors in a repeat get effective ids.  I have a repeat which looks like this:
>  <xforms:repeat bind="bind-things" id="repeat-things">
>   <xforms:input ref="." id="input-thing">
>     <xforms:label>Thing</xforms:label>
>   </xforms:input>
>   <xhtml:a href="#" id="anchor">Click Me</xhtml:a>
>   <xhtml:br/>
> </xforms:repeat>
>
>  This gets rendered as
>  <label id="repeat-begin-repeat-things" class="xforms-repeat-begin-end"></label>
> <label class="xforms-repeat-delimiter"></label>
> <label for="input-thing·1" class="xforms-label xforms-repeat-selected-item-1">Thing</label>
> <span id="input-thing·1" class="xforms-control xforms-input xforms-type-string xforms-repeat-selected-item-1">
> <span class="xforms-date-display"></span>
> <input id="input-input-thing·1" type="text" name="input-thing·1" value="one" class="xforms-input-input  xforms-type-string">
> <span class="xforms-showcalendar" id="showcalendar-input-thing·1"></span>
> <input class="xforms-input-time" value="">
> </span>
> <a href="#" id="anchor" onclick="alert(this.id)" class="xforms-repeat-selected-item-1">Click Me</a>
> <br class="xforms-repeat-selected-item-1">
> <label class="xforms-repeat-delimiter"></label>
> <label for="input-thing·2" class="xforms-label">Thing</label>
> <span id="input-thing·2" class="xforms-control xforms-input xforms-type-string">
> <span class="xforms-date-display"></span>
> <input id="input-input-thing·2" type="text" name="input-thing·2" value="two" class="xforms-input-input  xforms-type-string">
> <span class="xforms-showcalendar" id="showcalendar-input-thing·2"></span>
> <input class="xforms-input-time" value="">
> </span>
> <a href="#" id="anchor" onclick="alert(this.id)">Click Me</a>
> <br>
> <label class="xforms-repeat-delimiter"></label>
> <label for="input-thing" class="xforms-label xforms-disabled xforms-repeat-template"></label>
> <span id="input-thing" class="xforms-control xforms-input xforms-repeat-template">
> <span class="xforms-date-display"></span>
> <input id="input-input-thing" type="text" name="input-thing" value="" class="xforms-input-input">
> <span class="xforms-showcalendar" id="showcalendar-input-thing"></span>
> <input class="xforms-input-time" value="">
> </span>
> <a href="#" id="anchor" onclick="alert(this.id)" class="xforms-repeat-template">Click Me</a>
> <br class="xforms-repeat-template">
> <label id="repeat-end-repeat-things" class="xforms-repeat-begin-end"></label>
>
>  In other words, although the other elements within the repeat get an effective id of the form originalid.1, originalid.2 and so on within each repeat, the anchor gets the id "anchor" in each row.
>
>  Using the onclick alert I can tell that new anchors which are inserted using an <xforms:insert> do get an effective id with the repeat-number appended; it is just the repeats which correspond to items which were already in the instance data at the time the form was rendered that have the problem.
>
>
>  Cheers,
>      Dave McIntyre
>
>  Erik Bruchez wrote:
>
>
> Dave,
>
>  > I'm working on an application allows users to obtain values from an
>  > external webpage to fill in a form.  The idea is that they can click
>  > on a link which pops up a new window for the user to search for the
>  > value they want, and the new window uses JavaScript to communicate
>  > the value chosen back to the original page.
>
>  Ouch, one of those ;-)
>
>  > Next, I have to be able to use JavaScript to get that value into the
>  > XForm.
>  >
>  > As documented in
>  > http://www.orbeon.com/ops/doc/reference-xforms-ng#d1615550e4670 , this
>  > is possible by using
>  >
>  >     |var control = document.getElementById('myControl');
>  >     control.value = valueToSet;
>  > |
>  >
>  > So far so good.  However, I've been trying to reproduce the behaviour in
>  > the case where the control I want to set the value of is in a repeat,
>  > and it does not seem to behave in the same way.
>
>  This is because XForms controls have unique ids in your source
>  document, but as they are used in a repeat in the client, we give them
>  so-called "effective ids", of the form "myid.1", "myid.2", etc. This
>  is necessary because ids in a document (here an HTML or XHTML
>  document) must be unique.
>
>  > Looking at the HTML source of the page that is created, I see that
>  > the document.getElementById() actually returns a <span> element
>  > which contains the <input> element
>
>  Most likely you are obtaining a reference to the template for the
>  repeat. The <span> is normal in any case, whether you obtain a repeat
>  template or a control, as we encapsulate most controls within <span>
>  elements.
>
>  > so there must be some extra work going on to set the value in the
>  > <input> element and then update the model state.
>
>  Yes, our JavaScript code intercepts access to .value on the span, and
>  does the magic in the background. You should not expect that an
>  xforms:input will just produce an HTML input element and nothing else,
>  so this mechanism provides the flexibility of changing the underlying
>  HTML implementation while keeping the JavaScript code compatible.
>
>  > However, this behaviour does not seem to work with nodes within a
>  > repeat -- instead I have had to find the appropriate child of the
>  > <span> element, set its value, and then manually fire an onchange
>  > event.
>
>  This is a bug, or rather a missing feature. I have entered an RFE to
>  track this:
>
>
>  http://forge.objectweb.org/tracker/index.php?func=detail&aid=305806&group_id=168&atid=350207
>
>  But you have a solution that's working for now, right?
>
>  -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

>
>
>
> --
>
>
>
>
>               Dave McIntyre
>               Software Developer
>
>
>  2nd Floor, Orion House, cnr Enfield & Mary St, Mt Eden, PO Box 8273, Auckland, New Zealand
>        M.+64 21 212 8087 P.+64 9 638 0600 F.+64 9 638 0699
>        S.dave.mcintyre       [hidden email]       W.www.orionhealth.com
>
>
>
>
>
>
>
>  This e-mail and any attachments are intended only for the person to whom it is addressed and may contain privileged, proprietary, or other data protected from disclosure under applicable law. If you are not the addressee or the person responsible for delivering this to the addressee you are hereby notified that reading, copying or distributing this transmission is prohibited. If you have received this e-mail in error, please telephone us immediately and remove all copies of it from your system. Thank you for your co-operation.
>
>
>


--
Blog (XML, Web apps, Open Source):
http://www.orbeon.com/blog/



--
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
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet
Reply | Threaded
Open this post in threaded view
|

Re: Setting values of elements in a repeat

David McIntyre
Hi Alex,

We have a fix which is working for us now, but it relies on assumptions about the previous siblings and so on which I guess would be subject to change in later versions of OPS.  So having it as a bug in the tracker system is fine for us.

Thanks again,
    Dave

Alessandro Vernet wrote:
Hi Dave,

You are right, when we unroll the repeat, we add a suffix to the ids
of the XForms elements, but we don't do the same for HTML elements. I
created a bug for this:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=305939&group_id=168&atid=350207

Is this causing a problem for your application?

Alex

On 8/9/06, Dave McIntyre [hidden email] wrote:


 Sorry I didn't get back on this one sooner.

 I've noticed a small problem with the way that anchors in a repeat get effective ids.  I have a repeat which looks like this:
 <xforms:repeat bind="bind-things" id="repeat-things">
  <xforms:input ref="." id="input-thing">
    <xforms:label>Thing</xforms:label>
  </xforms:input>
  <xhtml:a href="#" id="anchor">Click Me</xhtml:a>
  <xhtml:br/>
</xforms:repeat>

 This gets rendered as
 <label id="repeat-begin-repeat-things" class="xforms-repeat-begin-end"></label>
<label class="xforms-repeat-delimiter"></label>
<label for="input-thing·1" class="xforms-label xforms-repeat-selected-item-1">Thing</label>
<span id="input-thing·1" class="xforms-control xforms-input xforms-type-string xforms-repeat-selected-item-1">
    <span class="xforms-date-display"></span>
    <input id="input-input-thing·1" type="text" name="input-thing·1" value="one" class="xforms-input-input  xforms-type-string">
    <span class="xforms-showcalendar" id="showcalendar-input-thing·1"></span>
    <input class="xforms-input-time" value="">
</span>
<a href="#" id="anchor" onclick="alert(this.id)" class="xforms-repeat-selected-item-1">Click Me</a>
<br class="xforms-repeat-selected-item-1">
<label class="xforms-repeat-delimiter"></label>
<label for="input-thing·2" class="xforms-label">Thing</label>
<span id="input-thing·2" class="xforms-control xforms-input xforms-type-string">
    <span class="xforms-date-display"></span>
    <input id="input-input-thing·2" type="text" name="input-thing·2" value="two" class="xforms-input-input  xforms-type-string">
    <span class="xforms-showcalendar" id="showcalendar-input-thing·2"></span>
    <input class="xforms-input-time" value="">
</span>
<a href="#" id="anchor" onclick="alert(this.id)">Click Me</a>
<br>
<label class="xforms-repeat-delimiter"></label>
<label for="input-thing" class="xforms-label xforms-disabled xforms-repeat-template"></label>
<span id="input-thing" class="xforms-control xforms-input xforms-repeat-template">
    <span class="xforms-date-display"></span>
    <input id="input-input-thing" type="text" name="input-thing" value="" class="xforms-input-input">
    <span class="xforms-showcalendar" id="showcalendar-input-thing"></span>
    <input class="xforms-input-time" value="">
</span>
<a href="#" id="anchor" onclick="alert(this.id)" class="xforms-repeat-template">Click Me</a>
<br class="xforms-repeat-template">
<label id="repeat-end-repeat-things" class="xforms-repeat-begin-end"></label>

 In other words, although the other elements within the repeat get an effective id of the form originalid.1, originalid.2 and so on within each repeat, the anchor gets the id "anchor" in each row.

 Using the onclick alert I can tell that new anchors which are inserted using an <xforms:insert> do get an effective id with the repeat-number appended; it is just the repeats which correspond to items which were already in the instance data at the time the form was rendered that have the problem.


 Cheers,
     Dave McIntyre
 


--
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