Re: [Xsltforms-support] Download action/control

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

Hi Mats,

 From the XForms Recommendation point of view, it is already possible to 
write an instance to disk using the "file:" protocol. As you know, for 
security reasons, browser vendors have decided not to allow file 
writing. XSLTForms includes a small Java applet which can write a file 
but, again for security reasons, I chose to first display the "Save as" 
dialog to alert the user and allow him/her to cancel this. XForms 
submissions have many attributes which can modify the serialization, 
concerning validation, relevance, for example. I am still perplex about 
the pertinence of defining submissions within the model: it sounds 
declarative but it might as well be considered as an action (and the 
submit action, indeed, has no parameter except the submission id...). 
Actions are written with an XML notation and I am not, also, that much 
convinced that a script notation would be worse. Because I am now 
implementing XQuery 3.1 in Javascript for XSLTForms v2, I am thinking of 
actions being written in XQuery syntax and annotations to bind XQuery 
functions to Javascript ones. Different XML-DB implementations already 
have their own XQuery library modules for standard purposes such as file 
management.

Anyway, I am happy to see that you succeeded in implementing what you 
need and my current concern is now how new XSLTForms v1 releases might 
not disturb this...

First, you added an attribute to the action: it means you had to modify 
xsltforms.xsl for generating the corresponding Javascript object. To 
prevent this, I should better expose all action attributes in the 
Javascript part not as separate parameters but as named properties 
(without namespace prefix...) within a unique Javascript object. What do 
you think?

Of course, the load Javascript object in xsltforms.js has been 
extended... Do you have any idea about how to help you to manage this 
with next builds?

Second, you are using your own functions in expressions. Are they pure 
Javascript functions or are they added to standard XPath functions. 
Actually, in both cases, you don't have to modify xsltforms.js, is that 
correct?

Best regards,

Alain

Le 07/04/2016 23:08, Mats Eklund a écrit :
> Hi Alain,
>
> Thought I should share with you the solution I arrived at in the end 
> for the problem how best to implement downloading of instances to disk:
>
> <xf:load target=”xsltforms:download” xsltforms:filename="data.xml">
>  <xf:resource 
> value="create-object-url(serialize(instance('data')),'text/xml')"/>
> </xf:load>
>
> Regards,
> Mats
>
> ------------------------------------------------------------------------
> Date: Mon, 21 Sep 2015 09:09:13 +0000
>
> Hi Alain,
>
> Somewhat related to my previous question how best leverage HTML 5 Web 
> Workers for async processing in XForms/XsltForms, I now have a similar 
> question, this time related to how best to leverage browsers' 
> capability to allow downloading of resources client-side utilizing the 
> HTML 5 @download attribute on the <a/> element combined with the 
> URL.createObjectURL() method of the File API 
> (http://www.w3.org/TR/FileAPI/#dfn-createObjectURL), and am interested 
> to get your opinion on possible options of extending XsltForms.
>
> Obviously it is possible already now to leverage these features in 
> XsltForms via the <xf:load resource="javascript:..."/> or <xf:script/> 
> elements, but I'm thinking this functionality should rather be exposed 
> through and encapsulated in a proper XForms extension element.
>
> I was first figuring around the following options:
>
>   * <xf:download ref/value=""/> as a control element, "mirroring" the
>     <xf:upload/> control already part of the XForms specification
>   * <xf:download ref/value=""/> as an _action_ element, allowing it to
>     be used in event handlers for the <xf:trigger/> element for
>     example, similar to the <xf:load/> action element. (I'm wondering
>     why the <xf:upload/> wasn't made an action element in XForms as
>     well...?!)
>
>
> At the same time, other options also exist:
>
>   * A custom @appearance attribute on the <xf:output/> element (as in
>     Orbeon Forms:
>     http://wiki.orbeon.com/forms/doc/developer-guide/xforms-controls/output-control?pli=1#TOC-Appearance-xxforms:download)
>   * Extended behavior of the <xf:submission resource="file://"
>     method="get/put".../> element... ...
>
>
> What are your thoughts here? Which option would make most sense in 
> your view?
>
> Regards,
> Mats
>
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support