xsltforms-support — XSLTForms support list

Re: [Xsltforms-support] inserting without redundancy?

[Klotz, L. <Lei...@xe...>]

Do you have anything already worked out that you could share as a partial example?

________________________________

From: Grégoire Colbert [mailto:gco...@gm...] 
Sent: Friday, June 04, 2010 10:47 AM
To: support xsltforms
Subject: [Xsltforms-support] inserting without redundancy?


Hi,

I have written a form where the user fills an instance with the "insert" element. Now, I want to abort the insertion process if the inserted node already exists in the destination instance. Is it possible?

Another possibility might be to add a test to ensure unicity of values in an instance? I don't know if this is possible neither. So any idea is welcome.

Thanks,
Grégoire

[Xsltforms-support] inserting without redundancy?

[Grégoire C. <gco...@gm...>]

Hi,

I have written a form where the user fills an instance with the "insert"
element. Now, I want to abort the insertion process if the inserted node
already exists in the destination instance. Is it possible?

Another possibility might be to add a test to ensure unicity of values in an
instance? I don't know if this is possible neither. So any idea is welcome.

Thanks,
Grégoire

[Xsltforms-support] Feature request

[Chris G. <cga...@gm...>]

Would it be possible to add another option in the xsltforms-options
processing instruction take the raw, untranslated XForms form and hide it in
the source code or show it in the debug region? When posting and returning
subsequent XForms, the returned XForms form is rendered to Javascript and it
makes things more challenging to debug when the problem is in one's XForms
form.

Re: [Xsltforms-support] How to choose when a JS class will be instanciated?

[Grégoire C. <gco...@gm...>]

Hi,

I solved this problem by attaching my global variable to the window.

Grégoire

Le 2 juin 2010 14:57, Grégoire Colbert <gco...@gm...> a écrit :

> Hi,
>
> I have written a JS class ("MapHandler") that should respond to various
> XForms events. The XForm tag that instanciates the class looks like:
>
> <xf:action ev:event="xforms-model-construct-done">
>    <xf:load>
>        <xf:resource value="concat('javascript:var mapHandler = new
> MapHandler();mapHandler.initialize(' ,
> instance('instance-configuration')/default/latitude , ',' ,
> instance('instance-configuration')/default/longitude , ')' )" />
>    </xf:load>
> </xf:action>
>
> As you can see, the "mapHandler" object is created just before the call to
> the "initialize" method. In this case, everything works fine.
>
> Today, I wanted to create another event handler, so I added this inside a
> <select1>:
>
> <xf:action ev:event="xforms-select">
>    <xf:load>
>        <xf:resource value="concat('javascript:mapHandler.centerMap(' ,
> instance('instance-towns')/latitude , ',' ,
> instance('instance-towns')/longitude , ')' )" />
>    </xf:load>
> </xf:action>
>
> *Problem* : this JS code fails when the "xforms-select" event is received.
> The error is "mapHandler is not defined".
>
> Looking at the generated code (using Mozilla's Web Developer extension), I
> see that my JS code is wrapped inside a call to XPath.create(). This rises a
> few questions...
>
> *Questions* :
> 1) Does this mean that the "mapHandler" variable is local to the
> XPath.create function?
> 2) If so, is it possible to declare a global JS variable through XSLTForms?
> 3) If so, how?
>
> Thank you,
> Grégoire
>
>

[Xsltforms-support] CSS problem from revision 412

[Grégoire C. <gco...@gm...>]

Hi,

In revision 412, there was a change in "xsltforms.xsl" about the CSS :

http://xsltforms.svn.sourceforge.net/viewvc/xsltforms/trunk/build/xsltforms.xsl?r1=412&r2=411&pathrev=412

I have declared my CSS like this :

  <css><link rel="stylesheet" type="text/css"
href="style/screen.css"></link></css>

With revisions 412 and 413, the use of "<xsl:apply-templates>" at line 101
seems to break my CSS. If I keep the same line but replace
"xsl:apply-templates" by "xsl:copy-of", it's ok again.

Grégoire

[Xsltforms-support] How to choose when a JS class will be instanciated?

[Grégoire C. <gco...@gm...>]

Hi,

I have written a JS class ("MapHandler") that should respond to various
XForms events. The XForm tag that instanciates the class looks like:

<xf:action ev:event="xforms-model-construct-done">
   <xf:load>
       <xf:resource value="concat('javascript:var mapHandler = new
MapHandler();mapHandler.initialize(' ,
instance('instance-configuration')/default/latitude , ',' ,
instance('instance-configuration')/default/longitude , ')' )" />
   </xf:load>
</xf:action>

As you can see, the "mapHandler" object is created just before the call to
the "initialize" method. In this case, everything works fine.

Today, I wanted to create another event handler, so I added this inside a
<select1>:

<xf:action ev:event="xforms-select">
   <xf:load>
       <xf:resource value="concat('javascript:mapHandler.centerMap(' ,
instance('instance-towns')/latitude , ',' ,
instance('instance-towns')/longitude , ')' )" />
   </xf:load>
</xf:action>

*Problem* : this JS code fails when the "xforms-select" event is received.
The error is "mapHandler is not defined".

Looking at the generated code (using Mozilla's Web Developer extension), I
see that my JS code is wrapped inside a call to XPath.create(). This rises a
few questions...

*Questions* :
1) Does this mean that the "mapHandler" variable is local to the
XPath.create function?
2) If so, is it possible to declare a global JS variable through XSLTForms?
3) If so, how?

Thank you,
Grégoire

Re: [Xsltforms-support] Using XML Prefixes (small bug)

[COUTHURES A. <ala...@ag...>]

Hi Steven,
> It all worked correctly except for <title>, which turned up in the body,  
> still with its prefix.
>   
This has been fixed in the latest SVN version (in fact <title> wasn't 
the only element with this problem...)

Thanks!

-Alain

Re: [Xsltforms-support] Roundtripping namespace prefixes

[COUTHURES A. <ala...@ag...>]

Hi Steven,
> I have written an XForm that is part of a pipeline, and so takes an  
> instance, changes it a bit, and then returns it.
>
> Unfortunately, all the prefixes are being renamed from something mnemonic  
> (like event:date), to something generic (like pre3:date).
>
> As you might imagine, the other people using the resulting instances are  
> not pleased. Any chance of roundtripping instances a bit better?
>   
XSLTForms now uses Javascript objects for storing nodes and 
serialization has to be done manually. This is more complex than I 
suspected. Prefixes are not preserved and this is causing problems in 
some situations such as the one you're describing.

Because there is also a performance problem with IE and Javascript, I 
have started to implement the use of an XML Data Island instead. 
Serialization will then be performed by native XML classes, I have 
already written the corresponding method and prefixes are preserved by 
it (a small XSLT transformation is used to eliminate specific meta data...).

I will probably need some weeks to complete this big change....

Thank you for waiting,

-Alain

Re: [Xsltforms-support] XML Data Islands integration with YahooUI library

[Brad J. <pjo...@ro...>]

I mean I like your ideas but since I am not intimately familiar with YUI I
am wondering if they can be implemented using YUI 3.1.1. For that matter can
YUI 3.1.1 even support the integration of XML Data Islands?

-- Brad

-----Original Message-----
From: Kostis Anagnostopoulos [mailto:ank...@gm...] 
Sent: May-31-10 11:09 AM
To: Brad Jones
Cc: XSLTForms support
Subject: Re: [Xsltforms-support] XML Data Islands integration with YahooUI
library

Hi Brad,

What do you mean?

Regards,
  Kostis

On Mon, May 31, 2010 at 6:01 PM, Brad Jones <pjo...@ro...> wrote:
> Great idea Kostis, but wouldn't it be better to implement YUI 3.1.x + ?
>
> Regards,
>
> Brad
>
> -----Original Message-----
> From: Kostis Anagnostopoulos [mailto:ank...@gm...]
> Sent: May-31-10 6:45 AM
> To: XSLTForms support
> Subject: [Xsltforms-support] XML Data Islands integration with YahooUI
> library
>
> Hi Alain,
>
> i think you decision to move with xml-dataislands is a sound
achitecturaly.
> Hope everything works out for the benefit of all of us.
>
> I suggest that it would be a great if the final result allows for
> integration of the xml-data-iuslands
> with the Yahou UI library.
> YUI library:  http://developer.yahoo.com/yui/2/
> XML Data Islands and YUI:
> http://www.yuiblog.com/blog/2008/10/15/datatable-260-part-one/
>
> Thus, one of the 2 most important defects of the XForms standard would
> vanish:
> Javasctipt enabled responsive Grids
> (html-tables with inplace-sorting and column reordering, etc).
> For intance,
> (The other most important defect is integration of XForms with
> Browser's History for a smooth user experience of the 'back' button.)
>
> Regards,
>  Kostis
>
>
----------------------------------------------------------------------------
> --
>
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>
>

Re: [Xsltforms-support] XML Data Islands integration with YahooUI library

[Kostis A. <ank...@gm...>]

Hi Brad,

What do you mean?

Regards,
  Kostis

On Mon, May 31, 2010 at 6:01 PM, Brad Jones <pjo...@ro...> wrote:
> Great idea Kostis, but wouldn't it be better to implement YUI 3.1.x + ?
>
> Regards,
>
> Brad
>
> -----Original Message-----
> From: Kostis Anagnostopoulos [mailto:ank...@gm...]
> Sent: May-31-10 6:45 AM
> To: XSLTForms support
> Subject: [Xsltforms-support] XML Data Islands integration with YahooUI
> library
>
> Hi Alain,
>
> i think you decision to move with xml-dataislands is a sound achitecturaly.
> Hope everything works out for the benefit of all of us.
>
> I suggest that it would be a great if the final result allows for
> integration of the xml-data-iuslands
> with the Yahou UI library.
> YUI library:  http://developer.yahoo.com/yui/2/
> XML Data Islands and YUI:
> http://www.yuiblog.com/blog/2008/10/15/datatable-260-part-one/
>
> Thus, one of the 2 most important defects of the XForms standard would
> vanish:
> Javasctipt enabled responsive Grids
> (html-tables with inplace-sorting and column reordering, etc).
> For intance,
> (The other most important defect is integration of XForms with
> Browser's History for a smooth user experience of the 'back' button.)
>
> Regards,
>  Kostis
>
> ----------------------------------------------------------------------------
> --
>
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>
>

Re: [Xsltforms-support] XML Data Islands integration with YahooUI library

[Brad J. <pjo...@ro...>]

Great idea Kostis, but wouldn't it be better to implement YUI 3.1.x + ?

Regards,

Brad

-----Original Message-----
From: Kostis Anagnostopoulos [mailto:ank...@gm...] 
Sent: May-31-10 6:45 AM
To: XSLTForms support
Subject: [Xsltforms-support] XML Data Islands integration with YahooUI
library

Hi Alain,

i think you decision to move with xml-dataislands is a sound achitecturaly.
Hope everything works out for the benefit of all of us.

I suggest that it would be a great if the final result allows for
integration of the xml-data-iuslands
with the Yahou UI library.
YUI library:  http://developer.yahoo.com/yui/2/
XML Data Islands and YUI:
http://www.yuiblog.com/blog/2008/10/15/datatable-260-part-one/

Thus, one of the 2 most important defects of the XForms standard would
vanish:
Javasctipt enabled responsive Grids
(html-tables with inplace-sorting and column reordering, etc).
For intance,
(The other most important defect is integration of XForms with
Browser's History for a smooth user experience of the 'back' button.)

Regards,
  Kostis

----------------------------------------------------------------------------
--

_______________________________________________
Xsltforms-support mailing list
Xsl...@li...
https://lists.sourceforge.net/lists/listinfo/xsltforms-support

[Xsltforms-support] Nill elements in XML result in failing validation

[Mark v. d. B. <ko...@gm...>]

Nill elements in XML fail validation for some reason. See example below:

<?xml-stylesheet href="xsltforms/xsltforms.xsl" type="text/xsl"?>
<?xsltforms-options debug="yes"?>
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:xf="http://www.w3.org/2002/xforms"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      xmlns:ev="http://www.w3.org/2001/xml-events"
      xml:lang="nl" lang="nl">
  <head>

  <title>Test</title>

  <xf:model id="overzicht">
    <xf:instance id="selectiescherm">
      <root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <date />
        <date xsi:nil="true"></date>
        <date xsi:nil="true" />
        <date></date>
        <date>2010-01-01</date>

        <bool />
        <bool xsi:nil="true"></bool>
        <bool xsi:nil="true" />
        <bool></bool>
        <bool>true</bool>
        <bool>false</bool>

        <number />
        <number xsi:nil="true"></number>
        <number xsi:nil="true" />
        <number></number>
        <number>1.23</number>
      </root>
    </xf:instance>
    <xf:bind nodeset="/root/date" type="xsd:date" />
    <xf:bind nodeset="/root/bool" type="xsd:boolean" />
    <xf:bind nodeset="/root/number" type="xsd:decimal" />
  </xf:model>

  </head>
  <body>
    <hr />
    <xf:repeat nodeset="/root/date">
      <xf:input ref=".">
        <xf:label>Date</xf:label>
      </xf:input>
      <br/>
    </xf:repeat>
    <hr />
    <xf:repeat nodeset="/root/bool">
      <xf:input ref=".">
        <xf:label>Boolean</xf:label>
      </xf:input>
      <br/>
    </xf:repeat>
    <hr />
    <xf:repeat nodeset="/root/number">
      <xf:input ref=".">
        <xf:label>Number</xf:label>
      </xf:input>
      <br/>
    </xf:repeat>
  </body>
</html>

The code above will show all elements formatted with only the last one
(with a valid value) of the sets not failing the validation. It would
be nice if XSLTForms would support the xsi:nill attibute. Is this a
bug or something else?

Thx,

Mark

[Xsltforms-support] XML Data Islands integration with YahooUI library

[Kostis A. <ank...@gm...>]

Hi Alain,

i think you decision to move with xml-dataislands is a sound achitecturaly.
Hope everything works out for the benefit of all of us.

I suggest that it would be a great if the final result allows for
integration of the xml-data-iuslands
with the Yahou UI library.
YUI library:  http://developer.yahoo.com/yui/2/
XML Data Islands and YUI:
http://www.yuiblog.com/blog/2008/10/15/datatable-260-part-one/

Thus, one of the 2 most important defects of the XForms standard would vanish:
Javasctipt enabled responsive Grids
(html-tables with inplace-sorting and column reordering, etc).
For intance,
(The other most important defect is integration of XForms with
Browser's History for a smooth user experience of the 'back' button.)

Regards,
  Kostis

[Xsltforms-support] Roundtripping namespace prefixes

[Steven P. <Ste...@cw...>]

I have written an XForm that is part of a pipeline, and so takes an  
instance, changes it a bit, and then returns it.

Unfortunately, all the prefixes are being renamed from something mnemonic  
(like event:date), to something generic (like pre3:date).

As you might imagine, the other people using the resulting instances are  
not pleased. Any chance of roundtripping instances a bit better?

Thanks!

Steven Pemberton

Re: [Xsltforms-support] Test page about XML Data Island

[Joe W. <jo...@gm...>]

Hi Alain,

>> What would you like to know about our results in various browsers when
>> running the page -- just that the page opened without errors, or the
>> actual times reported by the script?
>>
>
> Knowing for which browsers there are errors is clearly the most important.
>
> If everything works, "data" should be displayed for each table line (except
> for IE...). Times depend on machines, of course, but they should be
> decreasing for the 3 functions. Whether mobile phones have almost the same
> times or not is very interesting.

Here you go:


Test run on iPod Touch 2G, iPhone OS 3.1.3

1. Mobile Safari

#1	data	not evaluated
#2	not evaluated	not evaluated
#3	not evaluated	not evaluated

=====

Tests run on MacBook Air 2.13 GHz (Mid-2009), Mac OS X 10.6.3

1. Firefox 3.6.3

#1  	data  998ms
#2 	data 	304ms
#3 	data 	37ms

2. Google Chrome 5.0.375.55

#1	data	962ms
#2	data	142ms
#3	data	8ms

3. Safari 4.0.5

#1	data	417ms
#2	data	81ms
#3	data	9ms

4. Webkit nightly r.60376 (May 29, 2010)

#1	data	391ms
#2	data	65ms
#3	data	2ms

Re: [Xsltforms-support] Test page about XML Data Island

[COUTHURES A. <ala...@ag...>]

Hi Joe,
> What would you like to know about our results in various browsers when
> running the page -- just that the page opened without errors, or the
> actual times reported by the script?
>   
Knowing for which browsers there are errors is clearly the most important.

If everything works, "data" should be displayed for each table line 
(except for IE...). Times depend on machines, of course, but they should 
be decreasing for the 3 functions. Whether mobile phones have almost the 
same times or not is very interesting.

Thanks!

-Alain

Re: [Xsltforms-support] Test page about XML Data Island

[Joe W. <jo...@gm...>]

Hi Alain,

> Thank you for your feedbacks and suggestions for more performance!

What would you like to know about our results in various browsers when
running the page -- just that the page opened without errors, or the
actual times reported by the script?

Joe

Re: [Xsltforms-support] Test page about XML Data Island

[Alexander Ž. <sa...@st...>]

Tested on Mac OS 10.5.8 with:

Firefox 3.6.3

[Xsltforms-support] Test page about XML Data Island

[COUTHURES A. <ala...@ag...>]

Hi!

Before implementing the use of an XML Data Island by XSLTForms for 
XForms instance storage, it's, of course, very important to be sure that 
browsers support this well and help is welcome!

I have published a Javascript test page executing 3 different functions 
+ a specific function for Internet Explorer: 
http://www.agencexml.com/direct/island.htm

This has only been tested with standard browsers for Windows, two mobile 
browser simulators and test web sites (Konqueror fails again...). Don't 
hesitate to use different browsers for different platforms.

Thank you for your feedbacks and suggestions for more performance!

-Alain

[Xsltforms-support] no don't do it claudius

[Stephen C. <Ste...@ut...>]

Hi Claudius,

In my view your development of a second XSLT based XForms implementation 
is not necessary!

By all means test out some new ideas about how to do things but I feel 
that there is only a need for one such tool that is open-source and 
free! For development and testing efforts to be diluted makes no sense.

Remember, XSLTforms only exists because of a lack of mainstream browser 
support. Eventually I hope there is no need even for XSLTForms. Best to 
get one thing working really well and then people will see the benefits 
and the likelihood of native support in more browsers increases.

Also, I just came across the Xforms implementation from XMC2 "Formula", 
its cross-browser (no plugin) and it seems very fast, its based on GWT. 
But in theory you have to pay for it, again a good reason focus on 
improving XSLTForms.


Regards

Steve Cameron

[Xsltforms-support] Quick temporary fix for <range>

[Steven P. <Ste...@cw...>]

Until <range> is properly implemented, it would at least be useful if they  
turned up as <input>s, so that forms using them at least worked.

Best wishes,

Steven Pemberton

[Xsltforms-support] Using XML Prefixes (small bug)

[Steven P. <Ste...@cw...>]

I ran a quick test to see if xslt-forms dealt with XML prefixes properly:

<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../xsltforms-beta2/xsltforms/xsltforms.xsl"  
type="text/xsl"?>
<?xsltforms-options debug="no"?>
<h:html xmlns="http://www.w3.org/2002/xforms"
       xmlns:h="http://www.w3.org/1999/xhtml"
>
<h:head>
	<h:title>Integer</h:title>
	<h:style type="text/css">
	body { font-family: sans-serif}
	label { display: inline-block; width: 6em; margin: 0 1em }
	</h:style>

	<model id="m">
	    <instance>
                 <data xmlns="">
		      <number/>
	    	</data>
             </instance>
	    <bind nodeset="number" type="xsd:integer" />
	</model>
</h:head>
<h:body>
	<input ref="number"><label>Number</label>
		<alert>Must be a number</alert>
	</input>
</h:body>
</h:html>

It all worked correctly except for <title>, which turned up in the body,  
still with its prefix.

Best wishes,

Steven Pemberton

[Xsltforms-support] Submitting xf:select with underscores separated values?

[Grégoire C. <gco...@gm...>]

Hi,

The XForms 1.1 recommentation says that when multiple values from a
<xf:select> are sent, they are separated with spaces. Is it possible to
modify this to get underscore instead of spaces? If so, how?

Thank you,
Grégoire

Re: [Xsltforms-support] properties.doc.documentElement is null

[COUTHURES A. <ala...@ag...>]

Chris,

I have committed a fix for this escaping problem.

Thank you for your feedbacks!

-Alain
> Thank you for the suggestion. The XForms forms do double-duty as 
> REST-like XML remote procedure calls, so I can't expect the clients to 
> be able to support a complete XForms implementation. I have to keep it 
> simple.
>  
> The good news is that after beating on it all day long, I've come up 
> with a little patch to the xsltforms.js file which appears to fix the 
> issue with double-escaping entities. Before I turn it loose, I need to 
> make sure that it doesn't break anything else. Stay tuned.
>
> On Tue, May 25, 2010 at 7:57 PM, Stephen Cameron 
> <Ste...@ut... <mailto:Ste...@ut...>> wrote:
>
>     Hi Chris,
>
>     I'm not sure if this will help, but perhaps another approach to
>     what you are trying to achieve is possible.
>
>     If you use the xforms <switch> construct you can completely change
>     the appearance of the form and also do a submission at the time
>     you move from one <case> to another.
>
>     I think one of the main ideas in Xforms is that the view adapts to
>     the content of the model and the model can change due to user
>     interaction, so the idea of dynamically generating a form server
>     side does not make much sense in general.
>
>     The <switch> was a revelation for me when I discovered it, it pays
>     to read up before you start doing anything with Xforms.
>
>
>
>     -- 
>     Regards
>
>     Stephen Cameron
>
>     Data Programmer
>     Integrated Marine Observing System  (IMOS)
>     eMarine Information Infrastructure Project
>     University of Tasmania, Private Bag 21, Hobart, TAS 7001, Australia
>
>     Tel: +61 3 6226 8507
>     Fax: +61 3 6226 2997
>     Email: ste...@ut...
>     <mailto:ste...@ut...>
>     URL: http://www.imos.org.au/eMII.html
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>   

Re: [Xsltforms-support] Display two inputs for one field; one readonly the other editable

[Steven P. <Ste...@cw...>]

Off the top of my head:

	height: 3em; /* or whatever */
	width: 10em; /* or whatever */
	overflow: scroll;
	
On Wed, 26 May 2010 18:12:34 +0200, Mark van den Boomen  
<ko...@gm...> wrote:

> Done it the CSS way, but only one problem remains: when a value is
> long it will stretch the field, a inputfield wil allow the user to
> scroll through the contents of the box.
>
> 2010/5/26 Steven Pemberton <Ste...@cw...>:
>> On Wed, 26 May 2010 12:50:30 +0200, Mark van den Boomen  
>> <ko...@gm...>
>> wrote:
>>
>>> The problem is that the client wants to hold on to the look of an old
>>> (oracle forms) application, and those applications show readonly data
>>> with a disabled inputfield.
>>
>> That's just a CSS issue. Shouldn't be hard.
>>
>> Best wishes,
>>
>> Steven Pemberton
>>
>>>
>>> 2010/5/26 Steven Pemberton <Ste...@cw...>:
>>>>
>>>> On Wed, 26 May 2010 12:11:19 +0200, Mark van den Boomen
>>>> <ko...@gm...> wrote:
>>>>
>>>>> Given the following XML:
>>>>>
>>>>> <root>
>>>>>  <item>
>>>>>    <value>1</value>
>>>>>  </item>
>>>>>  <item>
>>>>>    <value>2</value>
>>>>>  </item>
>>>>>  <item>
>>>>>    <value>3</value>
>>>>>  </item>
>>>>> </root>
>>>>>
>>>>> The items are displayed in a table using xforms:repeat containing the
>>>>> editable inputs. Under the table is a xforms:input which should be
>>>>> disabled. If an user sets focus to one of the editable inputs then  
>>>>> the
>>>>> input under the table should show the value of the selected input in
>>>>> the table.
>>>>>
>>>>> The problem is when using a xforms:bind to set the value to readonly
>>>>> it will set both inputs readonly. Is there a way to set the readonly
>>>>> independent for the inputs?
>>>>
>>>> I'm not sure if I understand the problem, but why not use an <output>
>>>> under the table, and an input in the repeat?
>>>>
>>>> Best wishes,
>>>>
>>>> Steven Pemberton
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Mark
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Xsltforms-support mailing list
>>>>> Xsl...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Xsltforms-support mailing list
>>>> Xsl...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support