xsltforms-support — XSLTForms support list

Re: [Xsltforms-support] Bug with xforms:item xforms:label xforms:output ?

[Alain C. <ala...@ag...>]

Hi Steve,

> If the output within item is changed to plain text
> it loads successfully.  My expectation is that xforms:output
> is valid within xforms:label.
XSLTForms doesn't yet support xforms:output within 
xforms:item/xforms:label (xforms:itemset is generally used for variable 
items) and I don't know yet if it would be difficult to do it or not...
>
> Perhaps this is not the latest version?  I see mention of,
> e.g., r516 on the list here, but I do not know where to get
> that--is it a developers-only release?
For latest builds you have to access the SourceForge repositories for 
the project. The GIT repository is more stable than the SVN repository.

Thanks!

-Alain

Re: [Xsltforms-support] schema designer and xforms generator

[Dan M. <dan...@gm...>]

> I could also assign work to my students as class work.

If your students would like a place to put their examples please feel free
to add content to the XForms Wikibook here:

http://en.wikibooks.org/wiki/XForms

Our goal is to have a large number of examples to be used by students in a
classroom setting.

We can also put links to the working rendering of the forms on the google
code repository:

http://code.google.com/p/xforms-examples/

One of my goals is to have a "render-in" function that will render it in
all three form "players".

- Dan

On Wed, Nov 16, 2011 at 8:05 AM, William David Velasquez <
wi...@bi...> wrote:

> Hi Stephen,
>
> I'll be glad of being involved in your project.
>
> I run my own development bussines, but I´m also teaching XML
> technologies in an university here in Medellin Colombia.
>
> For 2012 we have a project for developing an XForms editor in the
> class.
>
> I you want, I can help you writing code (I already have two running
> aplications that uses XSLTForms), testing, translating (we speak spanish
> here) or whatever you may need. I could also assign work to my students
> as class work.
>
> There are already two Open Source projects you may check to get
> inspiration:
>
> Orbeon Forms: http://www.orbeon.com/
> Oryx: http://bpt.hpi.uni-potsdam.de/Oryx/WebHome
>
> Good luck,
>
>
>
>
> --
> William David Velasquez
> Laboratorio de Software Bitlab
> http://bitlab.com.co
> Movil 310 412 0218
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>



-- 
Dan McCreary
Semantic Solutions Architect
office: (952) 931-9198
cell: (612) 986-1552

Re: [Xsltforms-support] schema designer and xforms generator

[Philip F. <Phi...@ma...>]

Hello Stephen,

Although I'm in no position to provide any code to your project I am willing to help with previous experience and ideas as I have done work with transforming XSD into XHTML+XForms (using XSLT) before.

One of the biggest issues to start with was the structure of the schema as this will affect how you go about generating the model and the controls. You have a head start in that your editor may well impose a specific design pattern but if you are going to import other schemas then you'll need to consider how to transform third-party schemas to meet your design pattern.

It is possible to derive XForm data bindings from the document structure defined by the schema but then that may only hold for a subset of all possible instance structures. Certain classes of constraint can also be derived like enumerations and value restrictions. Use of XSD 1.1/Schematron assertions are also useful.

Inserting new nodes into an instance relies upon fragment templates that are pre-populated with required attributes and child elements. These too can be derived from the schema and placed into a 'template' instance in the model. Depending on how big and complex your schema is will decide how big your template instance is. This could get messy!

One other aspect to consider is the generation of submission elements. Where will the information for that come from? You do not want to embed that in the schema as that is application specific. It actually makes more sense to start with a service description that references a schema - that then binds the schema to the service and not the other way around. If you're interested in a service description (good RESTful practice IMHO) then I would suggest you look at the Web Application Description Language (WADL) as a possible candidate. A properly marked-up WADL description provides the necessary info to build your model's submission elements.

There is a lot of knitting required to do this but it is really good fun and I wish you well. Please e-mail me with any questions and I will do my best to help out.

Oh, and on the subject of knitting things together I also strongly suggest that you use XML Pipeline Processing Language (XProc) to do that as you will be bring together a number of different content source and applying a variety of transforms to it so breaking it down into pipeline steps is very useful.


Regards

Philip

From: Stephen Cameron [mailto:ste...@gm...]
Sent: Monday, November 14, 2011 10:53 PM
To: xsl...@li...
Subject: [Xsltforms-support] schema designer and xforms generator

Hello All,

I am currently working on a project to create an XML Schema Designer and XForms Generator.

The XML Schema Designer will itself be an 'XForm', the theory being that XForms is for building XML and that is what XML Schema is, so it should be possible (kind of a 'RepRap'<http://reprap.org/wiki/Main_Page> way of thinking).

The current Schema Designer UI version is online at http://collinta.com.au/schema2forms/designer.xml . This is a work in progress, more of a prototype than a beta.

I have the notion of how XForms are to be generated clear in my mind but not much progress made on that side as yet.

The main principles in the generation process are:

1. Schematron rules (constraints) are embedded into the XML Schema as xs:annotation/xs:appinfo/xxx tags and are used to add constraints to xf:bind elements
2. Generation of Xforms layout occurs by adding render-as attributes to the schema elements, also as xs:annotation/xs:appinfo/xxx tags.

The Designer will, I hope, be simple enough for folk without an understanding of XML Schema or Schematron to use.

I intend to put the project on sourceforge in the very near future, but if there is anyone with a desire to contribute (effort or ideas) please say.

Apart from wanting to create something useful, this project is in part motivated by the desire to demonstrate the power of XForms and particularly a native client-side implementation (which currently means XSLTForms) for creating effective complex UI's, making use of the XForms MVC 'engine'.

I'd be really happy if this was a collabortive effort. For me its just part of some other open-source projects (looking at XRX architectures) that I want to do.

If there are any serious offers of help, I'll document the design concepts as the highest priority.

All contributions will be acknowledged.

Regards

Steve Cameron

Re: [Xsltforms-support] schema designer and xforms generator

[William D. V. <wi...@bi...>]

Hi Stephen,

I'll be glad of being involved in your project.

I run my own development bussines, but I´m also teaching XML 
technologies in an university here in Medellin Colombia.

For 2012 we have a project for developing an XForms editor in the 
class.

I you want, I can help you writing code (I already have two running 
aplications that uses XSLTForms), testing, translating (we speak spanish 
here) or whatever you may need. I could also assign work to my students 
as class work.

There are already two Open Source projects you may check to get 
inspiration:

Orbeon Forms: http://www.orbeon.com/
Oryx: http://bpt.hpi.uni-potsdam.de/Oryx/WebHome

Good luck,




-- 
William David Velasquez
Laboratorio de Software Bitlab
http://bitlab.com.co
Movil 310 412 0218

[Xsltforms-support] Bug with xforms:item xforms:label xforms:output ?

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

Hi, Alain,

at

  http://oracc.museum.upenn.edu/label-output.xml

is a small test file which fails to load with beta3 dated
2011-02-27, the current version on sourceforge.

If the output within item is changed to plain text
it loads successfully.  My expectation is that xforms:output
is valid within xforms:label.

Perhaps this is not the latest version?  I see mention of,
e.g., r516 on the list here, but I do not know where to get
that--is it a developers-only release?

Thanks,

  Steve

Re: [Xsltforms-support] xf:toggle broken in r515

[Alain C. <ala...@ag...>]

Hello Efraim,

Oops! While adding the unload action for sub-forms, I accidentally 
erased the include command for the toggle action...

BTW, I modified the test case so it can run with rev. 516:

<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:xf="http://www.w3.org/2002/xforms"
xmlns:ev="http://www.w3.org/2001/xml-events">
<head>
<title>Toggle</title>
<xf:model>
<xf:instance id="data">
<data xmlns="">
<one>1</one>
<two>2</two>
</data>
</xf:instance>
</xf:model>
</head>
<body>
<div>
<xf:switch>
<xf:case id="one">
<xf:output ref="one"/>
</xf:case>
<xf:case id="two">
<xf:output ref="two"/>
</xf:case>
</xf:switch>
<xf:trigger>
<xf:label>ONE</xf:label>
<xf:toggle ev:event="DOMActivate" case="one"/>
</xf:trigger>
<xf:trigger>
<xf:label>TWO</xf:label>
<xf:toggle ev:event="DOMActivate" case="two"/>
</xf:trigger>
</div>
</body>
</html>


Thanks!

-Alain

Le 15/11/2011 07:07, Efraim Feinstein a écrit :
> Hi,
>
> In recent XSLTForms (at least since r514), use of xf:toggle results in
> an error on page load:
> XSLTForms Exception
> --------------------------
>
> Error initializing :
>
> ReferenceError: XsltForms_toggle is not defined
>       at xsltforms_initImpl (http://localhost:8080/test-toggle.xql:27:30)
>       at xsltforms_init (http://localhost:8080/test-toggle.xql:60:1)
>       at http://localhost:8080/test-toggle.xql:65:295
>       at onload (http://localhost:8080/test-toggle.xql:66:4)
>
> ReferenceError
>
> XsltForms_toggle is not defined
>
> A simple test form that demonstrates the error is below:
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:xf="http://www.w3.org/2002/xforms"
> xmlns:ev="http://www.w3.org/2001/xml-events">
> <head>
> <title>Toggle</title>
> <xf:model>
> <xf:instance id="data">
> <data xmlns="http://www.w3.org/1999/xhtml">
> <one>1</one>
> <two>2</two>
> </data>
> </xf:instance>
> </xf:model>
> </head>
> <body>
> <div>
> <xf:switch>
> <xf:case id="one">
> <xf:output ref="/one"/>
> </xf:case>
> <xf:case id="two">
> <xf:output ref="/two"/>
> </xf:case>
> </xf:switch>
> <xf:trigger>
> <xf:label>ONE</xf:label>
> <xf:toggle case="one"/>
> </xf:trigger>
> <xf:trigger>
> <xf:label>TWO</xf:label>
> <xf:toggle case="two"/>
> </xf:trigger>
> </div>
> </body>
> </html>
>
> Thanks,
>

Re: [Xsltforms-support] Performance Tips

[Gordon R. <gor...@co...>]

Hi Alain


Thanks for the prompt response. We'll upgrade our version of xsltforms and give it a try. 

 

The performance tips also sound useful and we'll change our xforms accordingly.

 

Thanks,

Gordon

 

From: Alain Couthures [mailto:ala...@ag...] 
Sent: 14 November 2011 19:58
To: Gordon Rogers
Cc: xsl...@li...
Subject: Re: [Xsltforms-support] Performance Tips

 

Hi Gordon,

Since rev. 512 in the SF SVN repository, the MIPs evaluation is performed according to nodes dependencies which means that a minimal number of reevaluations is effectively run.

You can also use the Profiler to locate which XPath expressions are requiring the most of the evaluation time.

Please avoid using // and use id() function as much as you can.

For Javascript own stuff, I added a js-eval() function to be called in a setvalue action for example.

Thank you for your feedbacks!

-Alain

Le 14/11/2011 11:25, Gordon Rogers a écrit : 

Hi

 

I was wondering if anyone has any tips for getting the best performance out of my xsltforms implementation. I have an xform that runs reasonably well on FF, Chrome and Safari, but which struggles on IE8. Whilst the difference in timings can in some part be accredited to IE's poor javascript engine I'm not satisfied that this is the whole reason.

 

The xform I've created has a single model and within that model there are 99 bindings, it seems to be that there is a direct correlation between the number of bindings and the performance of xsltforms. I want all of my data to be constructed and submitted at one point in time, so afaik that rules out splitting things into a separate model, although I would be interested to know if I've missed a trick somewhere.

 

Profiling of xsltforms.js doesn't point to any single method taking a long time to execute, rather it's the accumulation of the processing that takes time. Some examples:

 

XFControl.prototype.valueChanged - each time a value is changed on the form then the whole model is rebuilt. This means that in the case of my xform there is a loop of 99 calls to XFBind.prototype.recalculate. For any calculated bindings we then see a huge amount of calls around a number of evaluate methods e.g. in my xform for 5 calculated bindings there are 460 calls to LocationExpr.prototype.xPathStep. If I happen to write some custom javascript to set a few values on my form then the model is rebuilt each and every time. The method I use for setting a value is $(selector).get(0).xfElement.valueChanged(value); perhaps there is a more efficient way?

 

When I xf:insert on a repeat I see the model being rebuilt once, but the recalculation happens twice (which obviously triggers a revalidation and a refresh both times). Why go through the recalculation cycle more than once? With a large model this has obvious impact.

 

Any tips from those using xsltforms in anger would be welcome.

 

Thanks,

Gordon

 

Gordon Rogers

Senior Developer

Corelogic Limited

www.corelogic.co.uk <http://www.corelogic.co.uk/> 

Tel:       0131 550 0447

Email     gor...@co...

 

This document should only be read by those persons to whom it is intended, and its contents are private and confidential. If you receive this email message in error, notify the sender immediately and do not disclose, copy or distribute this message, or open any attachments

 






------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1






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

 

[Xsltforms-support] xf:toggle broken in r515

[Efraim F. <efr...@gm...>]

Hi,

In recent XSLTForms (at least since r514), use of xf:toggle results in 
an error on page load:
XSLTForms Exception
--------------------------

Error initializing :

ReferenceError: XsltForms_toggle is not defined
     at xsltforms_initImpl (http://localhost:8080/test-toggle.xql:27:30)
     at xsltforms_init (http://localhost:8080/test-toggle.xql:60:1)
     at http://localhost:8080/test-toggle.xql:65:295
     at onload (http://localhost:8080/test-toggle.xql:66:4)

ReferenceError

XsltForms_toggle is not defined

A simple test form that demonstrates the error is below:
<html xmlns="http://www.w3.org/1999/xhtml" 
xmlns:xf="http://www.w3.org/2002/xforms" 
xmlns:ev="http://www.w3.org/2001/xml-events">
<head>
<title>Toggle</title>
<xf:model>
<xf:instance id="data">
<data xmlns="http://www.w3.org/1999/xhtml">
<one>1</one>
<two>2</two>
</data>
</xf:instance>
</xf:model>
</head>
<body>
<div>
<xf:switch>
<xf:case id="one">
<xf:output ref="/one"/>
</xf:case>
<xf:case id="two">
<xf:output ref="/two"/>
</xf:case>
</xf:switch>
<xf:trigger>
<xf:label>ONE</xf:label>
<xf:toggle case="one"/>
</xf:trigger>
<xf:trigger>
<xf:label>TWO</xf:label>
<xf:toggle case="two"/>
</xf:trigger>
</div>
</body>
</html>

Thanks,

-- 
---
Efraim Feinstein
Lead Developer
Open Siddur Project
http://opensiddur.net
http://wiki.jewishliturgy.org

[Xsltforms-support] schema designer and xforms generator

[Stephen C. <ste...@gm...>]

Hello All,

I am currently working on a project to create an XML Schema Designer and
XForms Generator.

The XML Schema Designer will itself be an 'XForm', the theory being that
XForms is for building XML and that is what XML Schema is, so it should be
possible (kind of a 'RepRap' <http://reprap.org/wiki/Main_Page> way of
thinking).

The current Schema Designer UI version is online at
http://collinta.com.au/schema2forms/designer.xml . This is a work in
progress, more of a prototype than a beta.

I have the notion of how XForms are to be generated clear in my mind but
not much progress made on that side as yet.

The main principles in the generation process are:

1. Schematron rules (constraints) are embedded into the XML Schema as
xs:annotation/xs:appinfo/xxx tags and are used to add constraints to
xf:bind elements
2. Generation of Xforms layout occurs by adding render-as attributes to the
schema elements, also as xs:annotation/xs:appinfo/xxx tags.

The Designer will, I hope, be simple enough for folk without an
understanding of XML Schema or Schematron to use.

I intend to put the project on sourceforge in the very near future, but if
there is anyone with a desire to contribute (effort or ideas) please say.

Apart from wanting to create something useful, this project is in part
motivated by the desire to demonstrate the power of XForms and particularly
a native client-side implementation (which currently means XSLTForms) for
creating effective complex UI's, making use of the XForms MVC 'engine'.

I'd be really happy if this was a collabortive effort. For me its just part
of some other open-source projects (looking at XRX architectures) that I
want to do.

If there are any serious offers of help, I'll document the design concepts
as the highest priority.

All contributions will be acknowledged.

Regards

Steve Cameron

Re: [Xsltforms-support] Change instance via JavaScript?

[Alain C. <ala...@ag...>]

Hello,

The "javascript:" support in submission has been added in rev. 515 in 
the SF SVN repository.

Here is a test case:

<html  xmlns:xforms="http://www.w3.org/2002/xforms"xmlns:txs="http://www.agencexml.com/txs"xmlns="http://www.w3.org/1999/xhtml"xmlns:ev="http://www.w3.org/2001/xml-events"xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<head>
		<title>Javascript Submission</title>
		<xforms:model>
			<xforms:instance>
				<data  xmlns="">
					<value>Initial value</value>
				</data>

			</xforms:instance>
			<xforms:submission  method="get"serialization="none"replace="instance"targetref="value"resource="javascript:'&lt;value xmlns=&quot;&quot;&gt;Javascript value at '+(new Date())+'&lt;/value&gt;'"/>
		</xforms:model>
	</head>
	<body>
		<xforms:output  value="value"/>
		<xforms:submit>
			<xforms:label>Load from Javascript</xforms:label>

		</xforms:submit>
	</body>
</html>


As you can see, the resource is returning the serialization of the new 
instance.

Thank you for your feedbacks!

-Alain

Le 11/11/2011 13:33, st...@sa... a écrit :
> I am very inexperienced in XForms so I wonder if other XForms
> processors provide a javascript: submission facility as well?
>
> If it would be a defined way of doing this kind of thing only in
> XSLTForms I think it would still be interesting because although I
> have solved my immediate problem, I can't help thinking it is a
> bit of a hack.
>
> What I do now, in several different places in the UI, is this:
>
> Define both the target element and a dummy element in my
> instance:
>
> <xforms:instance id="pager">
> <pager-session xmlns="">
>           ...
> <list>(none)</list>
>           ...
> <dummy>dummy</dummy>
> </pager-session>
> </xforms:instance>
>
> Define a clickable button in my main form, and wrap it in a
> dialog which is never shown:
>
> <xforms:dialog id="listChangerDialog">
> <xforms:trigger id="listChanger" name="listChanger">
> <xforms:action ev:event="DOMActivate">
> <xforms:setvalue ref="instance('pager')/list"
>                              value="instance('pager')/dummy"/>
> <xforms:send submission="post-pager"/>
> </xforms:action>
> </xforms:trigger>
> </xforms:dialog>
>
> As you can see, I set the actual 'list' element value from a
> 'dummy' element.
>
> Now, the Advanced Search popup is its own XForm. It runs the
> search and leaves the results in a tmpdir which it needs to
> pass back to the main window, the pager which allows the
> user to page back and forward in the results.  So, in the
> popup XForm the instance is returned with a url:
>
> <url>javascript:oasNotify('pnveWbPgHo')</url>
>
> Which is loaded after the search completes:
>
> <xforms:submission action="/cgi-bin/oas" method="post"
>                          id="post-search"
>                          mediatype="application/xml"
>                          replace="instance">
> <xforms:action ev:event="xforms-submit-done">
> <xforms:load>
> <xforms:resource
>         value="instance('search')/result/url"/>
> </xforms:load>
> </xforms:action>
> </xforms:submission>
>
> The JS function oasNotify is:
>
> function oasNotify(list) {
>   var model = window.opener.window.document.getElementById("pagerModel");
>   var dummies = 
> model.getInstanceDocument("pager").getElementsByTagName("dummy");
>   dummies[0].firstChild.nodeValue = list;
>   window.opener.window.document.getElementById("listChanger").click();
> }
>
> That is, it gets the pager instance from the main window (opener)
> and sets the dummy value in it, then clicks the hidden trigger.
>
> That trigger (back to the top of this example) sets pager/list from
> pager/dummy--and that is where I started this discussion: the sticking
> point was that if you set pager/list directly, the refresh isn't
> called so the instance submitted doesn't have the updated list
> value.  By using an explicit xforms:setvalue to set it indirectly
> from pager/dummy, the refresh is triggered and the submitted list
> value is the new one.
>
> I have no illusions about whether this will work with other
> XForms processors--I'll just be happy if it doesn't break
> suddenly on XSLTForms (which I love, incidentally).
>
> If I understand your suggestion, the new code would basically
> cut out the copy from pager/dummy to pager/list because XSLTForms
> would understand that a *submission* with javascript URL might
> require a refresh, where it doesn't currently understand that
> a *load* with a javascript URL might require one.   I guess
> it would still be necessary to have the hidden trigger to
> send the post-pager submission (although I can imagine it
> all being wrapped in one JS routine; I just don't know how to
> do that offhand).
>
> If you need to see the context, you can launch the beta UI at:
>
>  http://oracc.museum.upenn.edu/etcsri/launch/p2
>
> Click on 'Advanced Search' and search for, say, 'lugal'
> (Sumerian for "king").
>
> That Advanced Search, btw Alain, includes the xforms:repeat inside
> an HTML table stuff you helped me with when I first started playing
> with this new UI last March--many thanks for that help, this help,
> and XSLTForms!
>
>  Steve
>
> Quoting Alain Couthures <ala...@ag...>:
>
>> Hello,
>>
>> Javascript URIs are not already supported in XSLTForms for submissions.
>>
>> I was just asking if it could be interesting because it shouldn't be
>> difficult to implement and it would be quite elegant.
>>
>> What do you think?
>>
>
>
>

Re: [Xsltforms-support] Performance Tips

[Alain C. <ala...@ag...>]

Hi Gordon,

Since rev. 512 in the SF SVN repository, the MIPs evaluation is 
performed according to nodes dependencies which means that a minimal 
number of reevaluations is effectively run.

You can also use the Profiler to locate which XPath expressions are 
requiring the most of the evaluation time.

Please avoid using // and use id() function as much as you can.

For Javascript own stuff, I added a js-eval() function to be called in a 
setvalue action for example.

Thank you for your feedbacks!

-Alain

Le 14/11/2011 11:25, Gordon Rogers a écrit :
>
> Hi
>
> I was wondering if anyone has any tips for getting the best 
> performance out of my xsltforms implementation. I have an xform that 
> runs reasonably well on FF, Chrome and Safari, but which struggles on 
> IE8. Whilst the difference in timings can in some part be accredited 
> to IE's poor javascript engine I'm not satisfied that this is the 
> whole reason.
>
> The xform I've created has a single model and within that model there 
> are 99 bindings, it seems to be that there is a direct correlation 
> between the number of bindings and the performance of xsltforms. I 
> want all of my data to be constructed and submitted at one point in 
> time, so afaik that rules out splitting things into a separate model, 
> although I would be interested to know if I've missed a trick somewhere.
>
> Profiling of xsltforms.js doesn't point to any single method taking a 
> long time to execute, rather it's the accumulation of the processing 
> that takes time. Some examples:
>
> XFControl.prototype.valueChanged -- each time a value is changed on 
> the form then the whole model is rebuilt. This means that in the case 
> of my xform there is a loop of 99 calls to 
> XFBind.prototype.recalculate. For any calculated bindings we then see 
> a huge amount of calls around a number of evaluate methods e.g. in my 
> xform for 5 calculated bindings there are 460 calls to 
> LocationExpr.prototype.xPathStep. If I happen to write some custom 
> javascript to set a few values on my form then the model is rebuilt 
> each and every time. The method I use for setting a value is 
> $(selector).get(0).xfElement.valueChanged(value); perhaps there is a 
> more efficient way?
>
> When I xf:insert on a repeat I see the model being rebuilt once, but 
> the recalculation happens twice (which obviously triggers a 
> revalidation and a refresh both times). Why go through the 
> recalculation cycle more than once? With a large model this has 
> obvious impact.
>
> Any tips from those using xsltforms in anger would be welcome.
>
> Thanks,
>
> Gordon
>
> *Gordon Rogers*
>
> Senior Developer
>
> Corelogic Limited
>
> www.corelogic.co.uk <http://www.corelogic.co.uk/>
>
> Tel:       0131 550 0447
>
> Email _go...@co... 
> <mailto:gor...@co...>_
>
> This document should only be read by those persons to whom it is 
> intended, and its contents are private and confidential. If you 
> receive this email message in error, notify the sender immediately and 
> do not disclose, copy or distribute this message, or open any attachments
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
>
>
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support

[Xsltforms-support] Performance Tips

[Gordon R. <gor...@co...>]

Hi

 

I was wondering if anyone has any tips for getting the best performance
out of my xsltforms implementation. I have an xform that runs reasonably
well on FF, Chrome and Safari, but which struggles on IE8. Whilst the
difference in timings can in some part be accredited to IE's poor
javascript engine I'm not satisfied that this is the whole reason.

 

The xform I've created has a single model and within that model there
are 99 bindings, it seems to be that there is a direct correlation
between the number of bindings and the performance of xsltforms. I want
all of my data to be constructed and submitted at one point in time, so
afaik that rules out splitting things into a separate model, although I
would be interested to know if I've missed a trick somewhere.

 

Profiling of xsltforms.js doesn't point to any single method taking a
long time to execute, rather it's the accumulation of the processing
that takes time. Some examples:

 

XFControl.prototype.valueChanged - each time a value is changed on the
form then the whole model is rebuilt. This means that in the case of my
xform there is a loop of 99 calls to XFBind.prototype.recalculate. For
any calculated bindings we then see a huge amount of calls around a
number of evaluate methods e.g. in my xform for 5 calculated bindings
there are 460 calls to LocationExpr.prototype.xPathStep. If I happen to
write some custom javascript to set a few values on my form then the
model is rebuilt each and every time. The method I use for setting a
value is $(selector).get(0).xfElement.valueChanged(value); perhaps there
is a more efficient way?

 

When I xf:insert on a repeat I see the model being rebuilt once, but the
recalculation happens twice (which obviously triggers a revalidation and
a refresh both times). Why go through the recalculation cycle more than
once? With a large model this has obvious impact.

 

Any tips from those using xsltforms in anger would be welcome.

 

Thanks,

Gordon

 

Gordon Rogers

Senior Developer

Corelogic Limited

www.corelogic.co.uk <http://www.corelogic.co.uk/> 

Tel:       0131 550 0447

Email     gor...@co...
<mailto:gor...@co...> 

 

This document should only be read by those persons to whom it is
intended, and its contents are private and confidential. If you receive
this email message in error, notify the sender immediately and do not
disclose, copy or distribute this message, or open any attachments

 

Re: [Xsltforms-support] Change instance via JavaScript?

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

I am very inexperienced in XForms so I wonder if other XForms
processors provide a javascript: submission facility as well?

If it would be a defined way of doing this kind of thing only in
XSLTForms I think it would still be interesting because although I
have solved my immediate problem, I can't help thinking it is a
bit of a hack.

What I do now, in several different places in the UI, is this:

Define both the target element and a dummy element in my
instance:

       <xforms:instance id="pager">
	<pager-session xmlns="">
           ...
	  <list>(none)</list>
           ...
	  <dummy>dummy</dummy>
	</pager-session>
       </xforms:instance>

Define a clickable button in my main form, and wrap it in a
dialog which is never shown:

	<xforms:dialog id="listChangerDialog">
	  <xforms:trigger id="listChanger" name="listChanger">
	    <xforms:action ev:event="DOMActivate">
	      <xforms:setvalue ref="instance('pager')/list"
                              value="instance('pager')/dummy"/>
	      <xforms:send submission="post-pager"/>
	    </xforms:action>
	  </xforms:trigger>
	</xforms:dialog>

As you can see, I set the actual 'list' element value from a
'dummy' element.

Now, the Advanced Search popup is its own XForm. It runs the
search and leaves the results in a tmpdir which it needs to
pass back to the main window, the pager which allows the
user to page back and forward in the results.  So, in the
popup XForm the instance is returned with a url:

   <url>javascript:oasNotify('pnveWbPgHo')</url>

Which is loaded after the search completes:

       <xforms:submission action="/cgi-bin/oas" method="post"
                          id="post-search"
                          mediatype="application/xml"
                          replace="instance">
	<xforms:action ev:event="xforms-submit-done">
	  <xforms:load>
	    <xforms:resource
		value="instance('search')/result/url"/>
	  </xforms:load>
	</xforms:action>
       </xforms:submission>

The JS function oasNotify is:

function oasNotify(list) {
   var model = window.opener.window.document.getElementById("pagerModel");
   var dummies =  
model.getInstanceDocument("pager").getElementsByTagName("dummy");
   dummies[0].firstChild.nodeValue = list;
   window.opener.window.document.getElementById("listChanger").click();
}

That is, it gets the pager instance from the main window (opener)
and sets the dummy value in it, then clicks the hidden trigger.

That trigger (back to the top of this example) sets pager/list from
pager/dummy--and that is where I started this discussion: the sticking
point was that if you set pager/list directly, the refresh isn't
called so the instance submitted doesn't have the updated list
value.  By using an explicit xforms:setvalue to set it indirectly
from pager/dummy, the refresh is triggered and the submitted list
value is the new one.

I have no illusions about whether this will work with other
XForms processors--I'll just be happy if it doesn't break
suddenly on XSLTForms (which I love, incidentally).

If I understand your suggestion, the new code would basically
cut out the copy from pager/dummy to pager/list because XSLTForms
would understand that a *submission* with javascript URL might
require a refresh, where it doesn't currently understand that
a *load* with a javascript URL might require one.   I guess
it would still be necessary to have the hidden trigger to
send the post-pager submission (although I can imagine it
all being wrapped in one JS routine; I just don't know how to
do that offhand).

If you need to see the context, you can launch the beta UI at:

  http://oracc.museum.upenn.edu/etcsri/launch/p2

Click on 'Advanced Search' and search for, say, 'lugal'
(Sumerian for "king").

That Advanced Search, btw Alain, includes the xforms:repeat inside
an HTML table stuff you helped me with when I first started playing
with this new UI last March--many thanks for that help, this help,
and XSLTForms!

  Steve

Quoting Alain Couthures <ala...@ag...>:

> Hello,
>
> Javascript URIs are not already supported in XSLTForms for submissions.
>
> I was just asking if it could be interesting because it shouldn't be
> difficult to implement and it would be quite elegant.
>
> What do you think?
>

Re: [Xsltforms-support] xsltforms-beta3 vs xsltforms-beta3RC vs ... ?

[Alain C. <ala...@ag...>]

This strange behavior of beta-3 has, apparently, already been fixed in 
the SVN latest builds because the extra xf:group elements are not 
required anymore.

Thank you for reporting this issue!

-Alain

Le 05/11/2011 00:34, C. M. Sperberg-McQueen a écrit :
> On Nov 4, 2011, at 3:21 PM, C. M. Sperberg-McQueen wrote:
>> Briefly, the problem appears to be that an xf:switch element
>> within an xf:repeat appears to be affecting the visibility of elements
>> which follow the switch and should be unaffected by it.
> I'm still interested in understanding the cause of the unexpected
> behavior (and fixing my form if I have an error), but it appears I
> have found a work-around: wrapping the elements in question
> in an xf:group seems to cause the form to behave as expected
> in both the beta-3RC and beta-3 releases.
>
> New versions of the test document now at
>
> http://blackmesatech.com/2011/11/xfq/test2-3.xhtml
> http://blackmesatech.com/2011/11/xfq/test2-3rc.xhtml
>
> If the beta3 release is doing something it oughtn't, perhaps
> knowing that the problem arises with xf:repeat but not with
> xf:group/xf:repeat may help track it down.  As far as I can tell
> from examining the form in Javascript debuggers, for some
> reason the div representing the repeat is being marked as
> disabled, in beta-3, as shown on element with id="clonedId29"
> when the 'Edit' button of line 2 is clicked in
>
> http://blackmesatech.com/2011/11/xfq/test-3.xhtml
>
> I hope this helps.
>

Re: [Xsltforms-support] Change instance via JavaScript?

[Alain C. <ala...@ag...>]

Hello,

Javascript URIs are not already supported in XSLTForms for submissions.

I was just asking if it could be interesting because it shouldn't be 
difficult to implement and it would be quite elegant.

What do you think?

Thanks!

-Alain

Le 09/11/2011 03:31, C. M. Sperberg-McQueen a écrit :
> I should mention that I do realize that a simple string-to-string
> function can be defined as an XPath extension as shown in the
> page on extensions at
> http://en.wikibooks.org/wiki/XSLTForms/XSLTForms_only_Extensions#User-Defined_Functions
> -- I'm just trying to get a grip on the method of using a submission to
> a Javascript URI as a technique for calling Javascript from an XForms
> (specifically XSLTForms) context.
>
> On Nov 8, 2011, at 6:55 PM, C. M. Sperberg-McQueen wrote:
>
>> On Nov 6, 2011, at 3:41 PM, Alain Couthures wrote:
>>>> ...
>>> Modifying an instance with Javascript instructions is always problematic
>>> because of dependencies to be set for refresh. It could also be very
>>> specific of a version of en implementation...
>>>
>>> Maybe the best way would be to just define an extension for submission:
>>> instead of "http:" or "file:", "javascript:" could be used to retrieve a
>>> string from a Javascript instruction.
>>>
>>> You could then externally activate a submit action for it.
>>>
>>> What do you think?
>>
>> Well, I don't know about the original poster, but I think you've just
>> explained to me how to handle a problem I was having without a
>> trip to the server.  Thank you!
>>
>> However, when I try to put this idea into practice, I encounter
>> a simple practical difficulty.  I want to use Javascript to manipulate a
>> string in the document, so I write a function called, say,
>> manipulate_string, which takes a string as argument and returns
>> a string as its result.
>>
>> I can write a submission element that specifies a call to this
>> function as the resource, and I can even specify the argument
>> (which I have placed in an instance document for the purpose),
>> thus:
>>
>>        <xf:submission id="hackstring"
>> 	 method="get"
>> 	 ref="instance('stringhack')/s"
>> 	 replace="text"
>> 	 targetref="instance('stringhack')/s"
>> 	>
>> 	<xf:resource
>> 	     value="concat('javascript:manipulate_string(&quot;', instance('stringhack')/s, '&quot;)')"
>> 	     />
>>        </xf:submission>
>>
>> But before submission, XForms appends "?s=" and the value of the
>> XPath expression in the 'ref' attribute, which has the effect that
>> the Javascript call is not recognized so my function never executes.
>>
>> Is there a way around this problem?
>>
>> -- 
>> ****************************************************************
>> * C. M. Sperberg-McQueen, Black Mesa Technologies LLC
>> * http://www.blackmesatech.com
>> * http://cmsmcq.com/mib
>> * http://balisage.net
>> ****************************************************************
>>
>>
>>
>>

[Xsltforms-support] tabs using repeat (setindex problem)

[Stephen C. <ste...@gm...>]

Hi Folks,

My previous request for assistance did not get any response, so I tried my
own test-case and didn't work as I expected it would. Something to do with
copying and pasting???

So there is a working version online at
http://collinta.com.au/schema2forms/setindex.xml

Clicking 'super tab 1' or 'super tab 2' should (via setindex) change the
top selected tab.

On the whole this method of turning a repeat into a set of tab labels works
in FF 7 but not in IE 9. Thats a minor thing for my project at present, but
any suggestions are welcome.

Thanks

Steve Cameron

Re: [Xsltforms-support] Change instance via JavaScript?

[C. M. Sperberg-M. <cm...@bl...>]

I should mention that I do realize that a simple string-to-string
function can be defined as an XPath extension as shown in the
page on extensions at 
http://en.wikibooks.org/wiki/XSLTForms/XSLTForms_only_Extensions#User-Defined_Functions
-- I'm just trying to get a grip on the method of using a submission to
a Javascript URI as a technique for calling Javascript from an XForms
(specifically XSLTForms) context.

On Nov 8, 2011, at 6:55 PM, C. M. Sperberg-McQueen wrote:

> 
> On Nov 6, 2011, at 3:41 PM, Alain Couthures wrote:
>>> ...
>> Modifying an instance with Javascript instructions is always problematic 
>> because of dependencies to be set for refresh. It could also be very 
>> specific of a version of en implementation...
>> 
>> Maybe the best way would be to just define an extension for submission: 
>> instead of "http:" or "file:", "javascript:" could be used to retrieve a 
>> string from a Javascript instruction.
>> 
>> You could then externally activate a submit action for it.
>> 
>> What do you think?
> 
> 
> Well, I don't know about the original poster, but I think you've just 
> explained to me how to handle a problem I was having without a
> trip to the server.  Thank you!
> 
> However, when I try to put this idea into practice, I encounter 
> a simple practical difficulty.  I want to use Javascript to manipulate a
> string in the document, so I write a function called, say,
> manipulate_string, which takes a string as argument and returns
> a string as its result.
> 
> I can write a submission element that specifies a call to this
> function as the resource, and I can even specify the argument
> (which I have placed in an instance document for the purpose),
> thus:
> 
>       <xf:submission id="hackstring"
> 	 method="get"
> 	 ref="instance('stringhack')/s"
> 	 replace="text"
> 	 targetref="instance('stringhack')/s"
> 	 >
> 	 <xf:resource
> 	     value="concat('javascript:manipulate_string(&quot;', instance('stringhack')/s, '&quot;)')"
> 	     />
>       </xf:submission>
> 
> But before submission, XForms appends "?s=" and the value of the
> XPath expression in the 'ref' attribute, which has the effect that 
> the Javascript call is not recognized so my function never executes.
> 
> Is there a way around this problem?
> 
> -- 
> ****************************************************************
> * C. M. Sperberg-McQueen, Black Mesa Technologies LLC
> * http://www.blackmesatech.com 
> * http://cmsmcq.com/mib                 
> * http://balisage.net
> ****************************************************************
> 
> 
> 
> 

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Re: [Xsltforms-support] Change instance via JavaScript?

[C. M. Sperberg-M. <cm...@bl...>]

On Nov 6, 2011, at 3:41 PM, Alain Couthures wrote:
>> ...
> Modifying an instance with Javascript instructions is always problematic 
> because of dependencies to be set for refresh. It could also be very 
> specific of a version of en implementation...
> 
> Maybe the best way would be to just define an extension for submission: 
> instead of "http:" or "file:", "javascript:" could be used to retrieve a 
> string from a Javascript instruction.
> 
> You could then externally activate a submit action for it.
> 
> What do you think?


Well, I don't know about the original poster, but I think you've just 
explained to me how to handle a problem I was having without a
trip to the server.  Thank you!

However, when I try to put this idea into practice, I encounter 
a simple practical difficulty.  I want to use Javascript to manipulate a
string in the document, so I write a function called, say,
manipulate_string, which takes a string as argument and returns
a string as its result.

I can write a submission element that specifies a call to this
function as the resource, and I can even specify the argument
(which I have placed in an instance document for the purpose),
thus:

       <xf:submission id="hackstring"
	 method="get"
	 ref="instance('stringhack')/s"
	 replace="text"
	 targetref="instance('stringhack')/s"
	 >
	 <xf:resource
	     value="concat('javascript:manipulate_string(&quot;', instance('stringhack')/s, '&quot;)')"
	     />
       </xf:submission>

But before submission, XForms appends "?s=" and the value of the
XPath expression in the 'ref' attribute, which has the effect that 
the Javascript call is not recognized so my function never executes.

Is there a way around this problem?

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

[Xsltforms-support] Fwd: xf:setindex support

[Stephen C. <ste...@gm...>]

Hi All,

I'm trying to make use of setindex on a repeat to change a selected 'tab',
but setindex is not being triggered.

Maybe there is a better approach but I do like this method so far.

Here is a test case:

<?xml-stylesheet href="xsltforms-beta3/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:ev="http://www.w3.org/2001/xml-events" xmlns:xs="
http://www.w3.org/2001/XMLSchema">
    <head>
        <style type="text/css">

            div.annotation{
            overflow:auto;
            padding:1em;
            }

            div.annotation >
            span.xforms-control{
            display:block;
            }

            div.annotation
            label.xforms-label{
            display:inline-block;
            width:100px;
            }

            div#select_element_detail_node,
            div#select_element_detail_node div{
            display:inline;
            color:black;
            }
        </style>
        <style>
            @namespace xf url("http://www.w3.org/2002/xforms");
            /* all the
            attributes of each tab, except the background
            color */
            .horiz_tab_menu
            xf|trigger {
            border-left: black solid 1px;
            border-top: black solid 1px;
            border-right:
            black solid 1px;
            border-bottom: 0px;
            font-weight: bold;
            font-family: Helvetica, sans-serif;
            font-size: .9em;
            margin-right: 5px;
            padding: 3px;
            /* the following only works under FireFox */
            /*-moz-border-radius: .5em .5em 0em
            0em;*/
            border-radius-topright:
            .5em;
            border-radius-topleft: .5em;
            }

            div.horiz_tab_menu div{
            display:
            inline;
            }

            div.horiz_tab_menu a{
            text-decoration: none;
            color: black;
            }

            div.horiz_tab_menu div.xforms-repeat-item-selected
            span.tab_title{
            padding: 0.2em;
            font-size: 1.2em;
            }

            /* the attributes of each div inside
            of a case
            */
            xf|switch
            xf|case div {
            border-top: solid black 0px;
            /*border-left: solid
            black 1px;
            border-right: solid
            black
            1px;
            border-bottom: solid black 1px;*/
            }
        </style>
        <xf:model id="model1">
            <xf:instance id="annotation_editor_tabs">
                <dummy xmlns="">
                    <tab title="super tab 1" case="element_annotation">
                        <tab title="Title and Description"
case="element_annotation_case_1" />
                        <tab title="Constraints"
case="element_annotation_case_2" />
                        <tab title="Rendering"
case="element_annotation_case_3" />
                    </tab>
                    <tab title="super tab 2"
case="element_details_annotation">
                        <tab title="Title and Description"
case="element_details_annotation_case_1" />

                        <tab title="Constraints"
case="element_details_annotation_case_2" />
                        <tab title="Rendering"
case="element_details_annotation_case_3" />
                    </tab>
                </dummy>
            </xf:instance>
        </xf:model>
    </head>
    <body>
        <div class="horiz_tab_menu">
            <xf:repeat nodeset="instance('annotation_editor_tabs')/*"
                id="detail_tabs_level_1">
                <xf:trigger appearance="minimal">
                    <xf:label>
                        <xf:output class="tab_title" ref="@title" />
                    </xf:label>
                    <xf:toggle ev:event="DOMActivate">
                        <xf:case value="@case" />
                    </xf:toggle>
                </xf:trigger>

            </xf:repeat>
        </div>
        <xf:switch>
            <xf:case id="element_annotation">
                <div class="horiz_tab_menu">
                    <xf:repeat
nodeset="instance('annotation_editor_tabs')/*[1]/tab"
                        id="detail_tabs_level_2">
                        <xf:trigger appearance="minimal">
                            <xf:label>
                                <xf:output class="tab_title" ref="@title" />
                            </xf:label>
                            <xf:toggle ev:event="DOMActivate">
                                <xf:case value="@case" />
                            </xf:toggle>
                        </xf:trigger>
                    </xf:repeat>
                </div>
                <div>
                    <xf:switch>
                        <xf:case id="element_annotation_case_1"
selected="true">
                            <div class="annotation">
                                tab 1-1
                            </div>
                        </xf:case>
                        <xf:case id="element_annotation_case_2">
                            <div class="annotation">
                                tab 2-1
                            </div>
                        </xf:case>
                        <xf:case id="element_annotation_case_3">
                            <div class="annotation">
                                tab 3-1
                            </div>
                        </xf:case>
                    </xf:switch>
                </div>
            </xf:case>
            <xf:case id="element_details_annotation">
                <div class="horiz_tab_menu">
                    <xf:repeat
nodeset="instance('annotation_editor_tabs')/*[2]/tab">
                        <xf:trigger appearance="minimal">
                            <xf:label>
                                <xf:output class="tab_title" ref="@title" />
                            </xf:label>
                            <xf:toggle ev:event="DOMActivate">
                                <xf:case value="@case" />
                            </xf:toggle>
                        </xf:trigger>
                    </xf:repeat>
                </div>
                <div>
                    <xf:switch>
                        <xf:case id="element_details_annotation_case_1"
selected="true">
                            <div class="annotation">
                                tab 1-2
                            </div>
                        </xf:case>
                        <xf:case id="element_details_annotation_case_2">
                            <div class="annotation">
                                tab 2-2
                            </div>
                        </xf:case>
                        <xf:case id="element_details_annotation_case_3">
                            <div class="annotation">
                                tab 3-2
                            </div>
                        </xf:case>
                    </xf:switch>
                </div>
            </xf:case>
        </xf:switch>
        <xf:trigger>
            <xf:label>select super tab 1</xf:label>
            <xf:setindex ev:event="DOMActivate"
repeat="detail_tabs_level_1" index="1"/>
        </xf:trigger>
        <xf:trigger>
            <xf:label>select super tab 2</xf:label>
            <xf:setindex ev:event="DOMActivate"
repeat="detail_tabs_level_1" index="2"/>
        </xf:trigger>
    </body>
</html>

Re: [Xsltforms-support] Change instance via JavaScript?

[Alain C. <ala...@ag...>]

Hello Steve,
> I have an XForm in one page which I would like to update from
> either a second page hosted by an iframe within the first,
> or from a popup opened by the page.
>
> I need to change an instance value in the parent form.  I can
> activate an xforms:trigger from an external page, but have not
> been able to see how to set the value with which to update the
> instance.
>
> So, I thought maybe updating the instance directly and then
> rebuild/refresh would work, but with that approach I can get
> as far as updating the nodeValue and then the rebuild/refresh
> does not update the display.
>
> What I would like to do is the kind of thing exemplified by
> some sample code (snarfed from the net) which is at:
>
>    http://oracc.museum.upenn.edu/p2/changeme.xml
>
> Any ideas?
Modifying an instance with Javascript instructions is always problematic 
because of dependencies to be set for refresh. It could also be very 
specific of a version of en implementation...

Maybe the best way would be to just define an extension for submission: 
instead of "http:" or "file:", "javascript:" could be used to retrieve a 
string from a Javascript instruction.

You could then externally activate a submit action for it.

What do you think?

Thanks!

-Alain

Re: [Xsltforms-support] xsltforms-beta3 vs xsltforms-beta3RC vs ... ?

[C. M. Sperberg-M. <cm...@bl...>]

On Nov 4, 2011, at 3:21 PM, C. M. Sperberg-McQueen wrote:
> 
> Briefly, the problem appears to be that an xf:switch element
> within an xf:repeat appears to be affecting the visibility of elements
> which follow the switch and should be unaffected by it.  

I'm still interested in understanding the cause of the unexpected
behavior (and fixing my form if I have an error), but it appears I
have found a work-around: wrapping the elements in question
in an xf:group seems to cause the form to behave as expected
in both the beta-3RC and beta-3 releases.

New versions of the test document now at 

http://blackmesatech.com/2011/11/xfq/test2-3.xhtml
http://blackmesatech.com/2011/11/xfq/test2-3rc.xhtml

If the beta3 release is doing something it oughtn't, perhaps
knowing that the problem arises with xf:repeat but not with
xf:group/xf:repeat may help track it down.  As far as I can tell
from examining the form in Javascript debuggers, for some
reason the div representing the repeat is being marked as
disabled, in beta-3, as shown on element with id="clonedId29"
when the 'Edit' button of line 2 is clicked in 

http://blackmesatech.com/2011/11/xfq/test-3.xhtml

I hope this helps.

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

[Xsltforms-support] xsltforms-beta3 vs xsltforms-beta3RC vs ... ?

[C. M. Sperberg-M. <cm...@bl...>]

I'm encountering a puzzling difficulty with a form I'm working on,
which appears to work fine when run with XSLTForms beta-3RC
but not when run with beta-3.

Briefly, the problem appears to be that an xf:switch element
within an xf:repeat appears to be affecting the visibility of elements
which follow the switch and should be unaffected by it.  The 
result is that parts of the document seem to disappear capriciously
when the user clicks certain buttons.  (In longer documents, the
sudden change in document length also leads to the appearance
that the browser is suddenly scrolling up in the document when
this happens -- and then scrolling down again when on further
mouse clicks those parts of the document reappear.)

I've placed two copies of a cut-down example on the Web at

  http://blackmesatech.com/2011/11/xfq/test-3.xhtml
  http://blackmesatech.com/2011/11/xfq/test-3rc.xhtml

which are identical except that they load different versions of XSLTforms,
and which exhibit the unexpected behaviors I'm encountering.
A detailed (and I fear somewhat pedantic) description of what I
am seeing and what I expect to see is included in the forms.

If any readers of this list can shed any light on the problem I'm
having, I'd be grateful.  It could either be a bug introduced between
beta-3RC and beta-3 of XSLTForms, or a bug in my form which
is hidden or tolerated for some reason in beta-3RC but becomes 
visible in beta-3.  

Thanks!

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

[Xsltforms-support] Change instance via JavaScript?

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

Hello,

I have an XForm in one page which I would like to update from
either a second page hosted by an iframe within the first,
or from a popup opened by the page.

I need to change an instance value in the parent form.  I can
activate an xforms:trigger from an external page, but have not
been able to see how to set the value with which to update the
instance.

So, I thought maybe updating the instance directly and then
rebuild/refresh would work, but with that approach I can get
as far as updating the nodeValue and then the rebuild/refresh
does not update the display.

What I would like to do is the kind of thing exemplified by
some sample code (snarfed from the net) which is at:

  http://oracc.museum.upenn.edu/p2/changeme.xml

Any ideas?

Thanks,

  Steve

[Xsltforms-support] behavior of % symbol in forms

[William D. V. <wi...@bi...>]

Hello,

I have a form where the user insert the % symbol in the text of a 
multiline input. (He writes somethign like "the customer offers 50% 
payment".

Actually my server is reporting an error "Invalid URL encoded character 
(% D) at position 222" when my form do POST or a PUT and the instance 
contains the % character.

My server is build with Delphi Websnap technology, and I personally 
don´t have many confidence in it.

My question is: Should I start looking for the problem in the server? 
or maybe there is some XSLTForms setting should I check?

Thanks for your advice,



-- 
William David Velasquez
Laboratorio de Software Bitlab
http://bitlab.com.co
Movil 310 412 0218

[Xsltforms-support] TinyMCE integration in rev. 512

[Alain C. <ala...@ag...>]

Hello,

Rev. 512 is about TinyMCE integration and an unmodified copy of this 
library has been added in the SF repositories.

Instead of an integration at control level, it's an integration at node 
level: specific types are defined to indicate that TinyMCE is to be used 
and that, eventually, some specific configuration is to be set.

I posted a question at the XML Schema mailing list about using an extra 
attribute for the restriction element and about using annotation/appinfo 
to store specific configuration. I was pleased to receive this answer 
from Michael Kay: "As far as I can see, both seem perfectly reasonable 
uses of the extensibility points provided in XSD.". External components 
integration in XSLTForms could be based on this in the future!

TinyMCE automatic discovery mechanism is inhibited (mode: "none") 
because it was in conflict with onload treatments in XSLTForms.

There are currently those limitations:

  * using setvalue action to externally force the RTE control value will
    compromise the use of the Undo capability
  * only the incremental mode is supported because the loss of focus is
    not, apparently, dispatched by TinyMCE

Please have a look at the test case below (check the path for TinyMCE 
script file before testing).

Thank you for your feedbacks!

-Alain
------------------------------------------------------------------------
<html xmlns="http://www.w3.org/1999/xhtml" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:ev="http://www.w3.org/2001/xml-events" 
xmlns:xsltforms="http://www.agencexml.com/xsltforms" 
xmlns:rte="http://www.agencexml.com/xsltforms/rte">
<head>
<title>TinyMCE Support</title>
<style type="text/css">
             .large-textarea textarea {
                 font-family: Courier, sans-serif;
                 height: 10em;
                 width: 500px;
             }
</style>
<script type="text/javascript" 
src="/xsltforms/scripts/tinymce_3.4.6/tiny_mce.js">/* */</script>
<model xmlns="http://www.w3.org/2002/xforms">
<schema xmlns="http://www.w3.org/2001/XMLSchema" 
targetNamespace="http://www.agencexml.com/xsltforms/rte">
<simpleType name="standardHTML1">
<restriction base="xsd:string" xsltforms:rte="TinyMCE"/>
</simpleType>
<simpleType name="standardHTML2">
<restriction base="xsd:string" xsltforms:rte="TinyMCE"/>
<annotation>
<appinfo>
                             {
                                 theme : "advanced",
                                 skin : "o2k7",
                                 plugins : 
"lists,pagebreak,style,layer,table,save,advhr,advimage,advlink,emotions,iespell,insertdatetime,preview,media,searchreplace,print,contextmenu,paste,directionality,fullscreen,noneditable,visualchars,nonbreaking,xhtmlxtras,template,inlinepopups,autosave",
                                 theme_advanced_buttons1 : 
"save,newdocument,|,bold,italic,underline,strikethrough,|,justifyleft,justifycenter,justifyright,justifyfull,styleselect,formatselect,fontselect,fontsizeselect",
                                 theme_advanced_buttons2 : 
"cut,copy,paste,pastetext,pasteword,|,search,replace,|,bullist,numlist,|,outdent,indent,blockquote,|,undo,redo,|,link,unlink,anchor,image,cleanup,help,code,|,insertdate,inserttime,preview,|,forecolor,backcolor",
                                 theme_advanced_buttons3 : 
"tablecontrols,|,hr,removeformat,visualaid,|,sub,sup,|,charmap,emotions,iespell,media,advhr,|,print,|,ltr,rtl,|,fullscreen",
                                 theme_advanced_buttons4 : 
"insertlayer,moveforward,movebackward,absolute,|,styleprops,|,cite,abbr,acronym,del,ins,attribs,|,visualchars,nonbreaking,template,pagebreak,restoredraft",
                                 theme_advanced_toolbar_location : "top",
                                 theme_advanced_toolbar_align : "left",
                                 theme_advanced_statusbar_location : 
"bottom",
                                 theme_advanced_resizing : true,
                             }
</appinfo>
</annotation>
</simpleType>
</schema>
<instance id="main">
<data xmlns="">
<richtext1>&lt;p&gt;Paragraph &lt;i&gt;number 
one&lt;/i&gt;&lt;/p&gt;</richtext1>
<richtext2>&lt;p&gt;Paragraph &lt;i&gt;number 
two&lt;/i&gt;&lt;/p&gt;</richtext2>
</data>
</instance>
<bind nodeset="richtext1" type="rte:standardHTML1"/>
<bind nodeset="richtext2" type="rte:standardHTML2"/>
</model>
</head>
<body>
<group xmlns="http://www.w3.org/2002/xforms">
<trigger>
<label>Hello World1!</label>
<setvalue ev:event="DOMActivate" ref="richtext1" value="'Hello 
&lt;strong&gt;World1&lt;/strong&gt;!'"/>
</trigger>
<textarea ref="richtext1" class="large-textarea"/>
<output value="richtext1"/>
</group>
<group xmlns="http://www.w3.org/2002/xforms">
<trigger>
<label>Hello World2!</label>
<setvalue ev:event="DOMActivate" ref="richtext2" value="'Hello 
&lt;strong&gt;World2&lt;/strong&gt;!'"/>
</trigger>
<textarea ref="richtext2" class="large-textarea"/>
<output value="richtext2"/>
</group>
</body>
</html>