Re: [Xsltforms-support] Download action/control

[Mats E. <mat...@li...>]

Hi Alain,
Thanks for your feedback!
The option of extending the xf:load action seemed to be the most natural option in the end. It's quite similar to how download actions are written in HTML 5, and basically corresponds to option #2 in my initial posting on the topic, however, leveraging the existing XForms xf:load element and the standard extensibility slots instead of inventing a non-standard download element. Both option #3 and #4 seemed unnatural for the task in the end.
With the numerous other extensions I had to do in my project I (temporarily) gave up the ability to do easy upgrades in the future. I may try to recover it at some point. For this one I had to do slight modifications to both xsltforms.xsl and xsltforms.js.
However, this particular extension could probably be implemented in more of plug-in manner if extension attributes were exposed to script methods, as you suggest. In my implementation I also allow the filename parameter to be specified via either an attribute or a child element (similar to the resource attribute), but I guess this could still be catered for in some generic way.
My custom XPath function "create-object-url(string-object, mediatype, encoding, lifetime)", which basically mimics the URL.createObjectURL() Javascript function, was necessary to add in order to make this work. It came in handy to solve some other problems as well. Such extensions to XSLTForms' XPath functions library are currently easy to add/plug-in. Like it should be!
Kind regards,Mats

On Sun, 10 Apr 2016 20:53:01 +0200 ala...@ag... wrote :

  
    
  
  
    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 lis...@li...://lists.sourceforge.net/lists/listinfo/xsltforms-support