xsltforms-support Mailing List for XSLTForms (Page 9)

Brought to you by: alain-couthures

xsltforms-support — XSLTForms support list

You can subscribe to this list here.

2009	Jan	Feb	Mar	Apr (1)	May (6)	Jun (9)	Jul (16)	Aug (5)	Sep (43)	Oct (36)	Nov (58)	Dec (43)
2010	Jan (79)	Feb (81)	Mar (107)	Apr (93)	May (85)	Jun (54)	Jul (64)	Aug (54)	Sep (45)	Oct (53)	Nov (34)	Dec (77)
2011	Jan (56)	Feb (53)	Mar (52)	Apr (66)	May (44)	Jun (16)	Jul (28)	Aug (5)	Sep (15)	Oct (21)	Nov (51)	Dec (46)
2012	Jan (16)	Feb (38)	Mar (47)	Apr (45)	May (41)	Jun (41)	Jul (72)	Aug (17)	Sep (10)	Oct (16)	Nov (29)	Dec (30)
2013	Jan (25)	Feb (13)	Mar (20)	Apr (25)	May (34)	Jun (8)	Jul (12)	Aug (9)	Sep (21)	Oct (19)	Nov (6)	Dec (2)
2014	Jan (14)	Feb (8)	Mar (7)	Apr (13)	May (33)	Jun (13)	Jul (6)	Aug (5)	Sep (5)	Oct (34)	Nov (7)	Dec
2015	Jan (1)	Feb (6)	Mar (17)	Apr (12)	May (10)	Jun (18)	Jul (31)	Aug (9)	Sep (3)	Oct (6)	Nov (19)	Dec (1)
2016	Jan (18)	Feb (4)	Mar (13)	Apr (19)	May	Jun (17)	Jul (7)	Aug	Sep (3)	Oct (6)	Nov (3)	Dec
2017	Jan (5)	Feb (17)	Mar (4)	Apr (8)	May (3)	Jun	Jul (8)	Aug (2)	Sep	Oct (5)	Nov (6)	Dec (4)
2018	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (6)	Nov	Dec (1)
2019	Jan	Feb	Mar (4)	Apr (2)	May (4)	Jun	Jul	Aug (2)	Sep (7)	Oct	Nov	Dec
2020	Jan (13)	Feb (17)	Mar (8)	Apr (11)	May (15)	Jun (11)	Jul	Aug	Sep	Oct	Nov	Dec (6)
2021	Jan (9)	Feb (26)	Mar (17)	Apr	May (7)	Jun (18)	Jul	Aug	Sep	Oct	Nov	Dec (10)
2022	Jan	Feb (1)	Mar	Apr	May (3)	Jun	Jul	Aug (2)	Sep (3)	Oct (2)	Nov (10)	Dec (1)
2023	Jan (10)	Feb	Mar (7)	Apr (8)	May (3)	Jun	Jul	Aug	Sep (8)	Oct (11)	Nov (8)	Dec (5)
2024	Jan (7)	Feb (3)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2025	Jan (4)	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

Flat | Threaded

<< < 1 .. 7 8 9 10 11 .. 109 > >> (Page 9 of 109)

Re: [Xsltforms-support] XsltForms 15 beta does not work for me

From: Alessandro <ca...@tu...> - 2020-05-13 17:38:12

Thanks Habs, I have downloaded again version 1.3 and now at least version 1.3 works (mine probably was messed-up). But I'd like also to understand why 15beta doesn't (I have existdb 5.2 installed)...
Cheers
Alex
-- 
 Inviato in modo sicuro con Tutanota. Ottieni la tua mailbox crittografata e senza pubblicità: 
 https://tutanota.com


13 mag 2020, 16:16 da ge...@us...:

> On Wed, 13 May 2020, Alessandro via Xsltforms-support wrote:
>
>> Dear all,
>> after reinstalling eXist-db I have lost the xsltforms release I was using and the last beta release does not seem to be working anymore. All I get is a
>> permanent "...Loading..." square message... The following is the XForm I'd like to style (already recently reviewed by Tim Thompson):
>>
>
>
> Hi there,
>
> What version were you using ?
>
> v1.3 can still be had here (unless its pulling the newest beta...you would need to check just in case):
>
> http://sourceforge.net/project/platformdownload.php?group_id=242651
>
>
> (it is the link of here: http://www.agencexml.com/xsltforms.htm)
>
> If you already tried this, sorry for the noise.
>
> Regards
> Habs
> --- Sent using Alpine/Pine, probably the best MUA ---
>

Re: [Xsltforms-support] XsltForms 15 beta does not work for me

From: Habs <ge...@us...> - 2020-05-13 14:17:03

On Wed, 13 May 2020, Alessandro via Xsltforms-support wrote:

> Dear all,
> after reinstalling eXist-db I have lost the xsltforms release I was using and the last beta release does not seem to be working anymore. All I get is a
> permanent "...Loading..." square message... The following is the XForm I'd like to style (already recently reviewed by Tim Thompson):


Hi there,

What version were you using ?

v1.3 can still be had here (unless its pulling the newest beta...you would 
need to check just in case):

http://sourceforge.net/project/platformdownload.php?group_id=242651


(it is the link of here: http://www.agencexml.com/xsltforms.htm)

If you already tried this, sorry for the noise.

Regards
Habs
--- Sent using Alpine/Pine, probably the best MUA ---

[Xsltforms-support] XsltForms 15 beta does not work for me

From: Alessandro <ca...@tu...> - 2020-05-13 13:57:55

Dear all,
after reinstalling eXist-db I have lost the xsltforms release I was using and the last beta release does not seem to be working anymore. All I get is a permanent "...Loading..." square message... The following is the XForm I'd like to style (already recently reviewed by Tim Thompson):

xquery version "3.0";

import module namespace my_funcs="http://www.my_funcs.net" at "modules/my_app_functions_2.xql";

declare variable $app_collection := 'resources/data';

declare variable $fold_id := request:get-parameter("f_id", "");
declare variable $tab_id := request:get-parameter("t_id", "");
declare variable $table_title := request:get-parameter('t_title', '');
declare variable $arch_id := request:get-parameter("arch_id", "");

let $login := xmldb:login($app_collection, 'admin', 'password')

let $categories := doc(concat($app_collection, '/', $my_funcs:my_archive))/archivi/archivio[@id=$arch_id]/cartella[@id=$fold_id]/tabella[@id=$tab_id]/legenda

let $new_value := doc(concat($app_collection, '/', $my_funcs:my_archive))/archivi/options/new_categoria

let $form :=
<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" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
    <script src="resources/data/my_javascripts.js"/>
   
    <style type="text/css">
    <!--/*--><css><![CDATA[/**/
       
        h1 {
        padding:0px 0 0 50px;
        font-family: 'Aller Display',Georgia, Times New Roman, Sans;
        font-size:20pt;
        font-weight:400;
        color:red;
        letter-spacing:2px;
        line-height:1.2em;
        }
       
        .my_button {
            height:16pt;
            font-size:10pt;
            color: red;
          }
         
        .my_special_button {
            font-size:10pt;
            padding: 1px;
          }
     
        .my_box {
            background-color: #ECF1C4;
          }
        
         label, legend {
            font-weight: bold;
         }
    
        .header {
            color: white;
            background-color: gray;
            font-weight: bold;
            display: inline-block;
            width: 607px;
            margin-left: -1px;
          }
         
        input {
               font-size: 10pt;
               width: 300px;
               background-color: #ECF1C4;
               margin-right: 0;
               border: 0;
          }
     
        .list-table tbody { display:block; margin: -1px; }
         
        .list-table td {
               border: 1px solid #ECF1C4;
          }
         
        .list-table tr {
               height:20px;
          }
     
     
      .list-table {
          border-collapse: collapse;
          background-color: #ECF1C4;
        }
     
      .leftColumn, .rightColumn {
          font-size: 11pt;
          display: inline-block;
        }
     
      .leftColumn {
          margin-left: 0px;
          margin-right: 0;
        }
     
      .rightColumn {
         left: 0;
         margin-left: 0px;
        }
     
      fieldset {
         width: 605px;
         font-size: 10pt;
         margin-left: 20px;
        }
       
    /*]]>*/<!--/*--></css><!--*/-->
    </style>
   
    <xf:model>
            
       <xf:instance id="my-category-list">
         <data xmlns="">{$categories}</data>
       </xf:instance>
      
       <xf:submission id="save-to-local-file" method="post" action="query_form_list_2.xq?arch_id={$arch_id}&amp;f_id={$fold_id}&amp;t_id={$tab_id}" replace="instance" instance="my-category-list">
            <xf:action ev:event="xforms-submit-done">
                <xf:message level="modal">Dati correttamente aggiornati!</xf:message>
            </xf:action>
            <xf:action ev:event="xforms-submit-error">
                <xf:message level="modal">Si è verificato un errore in fase di salvataggio!</xf:message>
            </xf:action>
        </xf:submission>
    </xf:model>
   
  </head>
  <body>
      <center>
         
      <h1>Categorie tabella: {$table_title}</h1>
     
      <xf:group ref="instance('my-category-list')/legenda">
      <fieldset>
         <legend>Lista delle categorie attualmente disponibili</legend>
         <div class="header">
            <table border="0">
             <tr>
                 <td>
                     <div class="leftColumn">Abbreviazione</div>
                 </td>
                 <td style="width: 205px;"/>
                 <td>
                     <div class="rightColumn">Nome categoria per esteso</div>
                 </td>
             </tr>
            </table>
         </div>
        
         <xf:repeat id="list" nodeset="categoria">
             <table border="0" id="categories" class="list-table">
            
             <tr>
                 <td>
                     <xf:input ref="@id" class="leftColumn" />
                 </td>
                 <td>
                     <xf:input ref="text()" class="rightColumn" />
                 </td>
             </tr>
            
             </table>
         </xf:repeat>
      </fieldset>
     
      <br/>
     
      <table border="0">
        <tr>
            <td style="width: 15px;"/>
            <td> <!--  style="padding-top: 15pt;" -->
              <xf:trigger>
                 <xf:label><div class="my_special_button">Elimina riga selezionata dalla lista delle categorie</div></xf:label>
                 <xf:action ev:event="DOMActivate">
                    <xf:delete nodeset="categoria" at="index('list')" />
                 </xf:action>
              </xf:trigger>
            </td>
            <td style="width: 15px;"/>
            <td>
               <xf:trigger>
                    <xf:label><div class="my_special_button">Inserisci nuova categoria dopo riga selezionata</div></xf:label>
                    <xf:action ev:event="DOMActivate">
                       <xf:insert nodeset="categoria" at="index('list')" position="after" />
                       <xf:setvalue ref="categoria[index('list')]/@id" value="'{$new_value}'"/>
                       <xf:setvalue ref="categoria[index('list')]/text()" value="'{$new_value}'"/>
                       <!--<xf:setvalue ref="SelectedRow" value="index('list')" />-->
                    </xf:action>
               </xf:trigger>
            </td>
       </tr>
     </table>
    
      <br/>
   
        <table border="0">
           <tr>
                <td style="width: 275px;"/>
               
                <td >
            	    <xf:trigger>
                      <xf:label class="my_button">&#10094;&#10094;Torna&#10094;&#10094;indietro</xf:label>
                      <xf:action ev:event="DOMActivate">
                       <xf:load resource="javascript:GoBack()" />
                      </xf:action>
                    </xf:trigger>
                </td>
           </tr>
           <tr>
                <td style="height: 40px;"/>
                <td> <!--  style="padding-top: 15pt;" -->
                    <xf:submit submission="save-to-local-file">
                       <xf:label><div>Salva modifiche</div></xf:label>
                    </xf:submit>
                </td>
           </tr>
        </table>
     
      </xf:group>
      </center>
  </body>
</html>
let $xslt-pi := processing-instruction xml-stylesheet {'type="text/xsl" href="../xsltforms15/xsltforms.xsl"'}
  return ($xslt-pi,$form)

Many thanks
Alex
-- 
Inviato in modo sicuro con Tutanota. Ottieni la tua mailbox crittografata e senza pubblicità: 
https://tutanota.com

Re: [Xsltforms-support] new beta release testing - possible styling bug - display:block

From: Habs <ge...@us...> - 2020-05-10 20:38:38

On Sun, 10 May 2020, Steven Pemberton wrote:

> The current stylesheet sets everything to display: none, and then adds the 
> cases when it is not display: none.
>
> I think the cure is to do it the other way round: set the default to visible 
> (inline/block) for those elements where this makes sense (like input, but not 
> the actions, model etc.) and then specify explicitly the cases where display 
> is none.
>
> In that way, user added CSS (which is only interested in when the elements 
> are visible) can override the default case. The long, specific selectors for 
> display: none will never need to be overridden.
>
> Steven
>
> On Sun, 10 May 2020 16:06:25 +0200, Alain Couthures 
> <ala...@ag...> wrote:
>
>> Maybe it could be better if the XSLT stylesheet could read some option to 
>> generate a reference to another CSS stylesheet >(instead of xsltforms.css).
>> What do you think?
>> --Alain
>>> Le 10 mai 2020 à 12:41, Steven Pemberton <ste...@cw...> a écrit 
>>> :
>>> I have this problem too, and I'm trying to trace how to fix it. The 
>>> xsltforms css has rules like:
>>>  xforms-input[xf-bound]:not([xf-notrelevant]) {display: inline}
>>> which have very high 'specificity'. The CSS1 spec* says:
>>> * Find all declarations that apply to the element/property in question. 
>>> Declarations apply if the selector >>matches the element in question. If 
>>> no declarations apply, the inherited value is used. If there is no 
>>> inherited >>value (this is the case for the 'HTML' element and for 
>>> properties that do not inherit), the initial value is >>used.* Sort the 
>>> declarations by explicit weight: declarations marked '!important' carry 
>>> more weight than unmarked >>(normal) declarations.* Sort by origin: the 
>>> author's style sheets override the reader's style sheet which override the 
>>> UA's default >>values. An imported style sheet has the same origin as the 
>>> style sheet from which it is imported.* Sort by specificity of selector: 
>>> more specific selectors will override more general ones. To find the 
>>> >>specificity, count the number of ID attributes in the selector (a), the 
>>> number of CLASS attributes in the >>selector (b), and the number of tag 
>>> names in the selector (c). Concatenating the three numbers (in a number 
>>> >>system with a large base) gives the specificity.
>>> "An imported style sheet has the same origin as the style sheet from which 
>>> it is imported." means, I think, that >>the xsltforms.css has the same 
>>> importance as the style in the form itself.
>>> Using !important is in general a poor solution, because it overrides other 
>>> rules in your own styling, though it >>would often work.
>>> I think, strictly speaking, you have to use the same selector or a more 
>>> specific one than in the xsltforms.css
>>> So to change the display value, you have to use
>>>  xforms-input[xf-bound]:not([xf-notrelevant]) {display: block}
>>> I will be experimenting with the xsltforms.css in the coming weeks to see 
>>> if we can improve on this situation, >>because it was easier to do in the 
>>> previous xsltforms.
>>> Best wishes,
>>> Steven
>>> * The latest CSS spec is harder to read. Check it for yourself at 
>>> https://www.w3.org/TR/selectors/#specificity
>>> A rule of relevance is:
>>> The specificity of an :is(), :not(), or :has() pseudo-class is replaced by 
>>> the specificity of the most specific >>complex selector in its selector 
>>> list argument.
>>> 
>>> 
>>> On Sun, 10 May 2020 09:57:26 +0200, Alain Couthures 
>>> <ala...@ag...> wrote:
>>>> Hello Habs,
>>>> Sorry, I am not a CSS expert but I think that, in such as situation, you 
>>>> have to add !important in >>>your own CSS rule to override the default 
>>>> behaviour.
>>>> Thank you for your feedback!
>>>> --Alain
>>>>> Le 22 avril 2020 à 15:03, Habs < ge...@us...> a écrit :
>>>>> 
>>>>> 
>>>>> Hello all :)
>>>>> Using the new beta from here, www.agencexml.com/1.5beta/xsltforms.zip :
>>>>> xf:input ( xforms-input when using a css inspecting tool ) defaults 
>>>>> to'display:inline'.
>>>>> I can only seem to style a xf:input as 'display:block' by using aninline 
>>>>> style on the element
>>>>> ie. <xf:input ... style="display: block">
>>>>> and not in a external ref'd style sheet, or a style section within 
>>>>> 'head',from where all other styling on the element appears to apply 
>>>>> withoutissue.
>>>>> ie. xforms-input {display: block;}
>>>>> Is it something I am getting wrong, or a bug, or ?
>>>>> Thank you and regardsHabs
>>>>> --- Sent using Alpine/Pine, probably the best MUA ---
>>>>> 
>>>>> _______________________________________________Xsltforms-support mailing 
>>>>> lis...@li...https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>> 
>>> 
>

Thank you for the replies Steven and Alain.

I do too, not feel that using '!important' is the correct way forward. 
Until this latest Xsltforms release, I was not experiencing this problem - 
fortuitously or otherwise :-)

I will have another pick through following the comments. I have not got 
into much detail yet and it is my first test and conversion of a few forms 
working previously.

Thank you and regards. Best wishes.
Habs

--- Sent using Alpine/Pine, probably the best MUA ---

Re: [Xsltforms-support] new beta release testing - possible styling bug - display:block

From: Steven P. <ste...@cw...> - 2020-05-10 20:02:04

How about setting <body> to display: none until xforms-ready happens?

Steven

On Sun, 10 May 2020 21:28:59 +0200, Alain Couthures  
<ala...@ag...> wrote:

> In previous XSLTForms release, all controls were disabled, with a CSS  
> class, before evaluation to limit flickering when >building, especially  
> sensible for switch/case with just one selected case.
> This release does not use any CSS class but extra attributes which is  
> lighter for Javascript processing.
> The XSLT transformation is not even required if an author directly uses  
> the generated HTML5 notation. In this case, ><xforms-input  
> xf-ref="a"><xforms-label>A: </xforms-label></xforms-input> should not be  
> displayed until the extra xf-bound >attribute is added accordingly.
> It sounds then impossible to set the default to visible, doesn't it?
> --Alain
>> Le 10 mai 2020 à 19:33, Steven Pemberton <ste...@cw...> a  
>> écrit :
>> The current stylesheet sets everything to display: none, and then adds  
>> the cases when it is not display: none.
>> I think the cure is to do it the other way round: set the default to  
>> visible (inline/block) for those elements >>where this makes sense  
>> (like input, but not the actions, model etc.) and then specify  
>> explicitly the cases where >>display is none.
>> In that way, user added CSS (which is only interested in when the  
>> elements are visible) can override the default >>case. The long,  
>> specific selectors for display: none will never need to be overridden.
>> Steven
>> On Sun, 10 May 2020 16:06:25 +0200, Alain Couthures  
>> <ala...@ag...> wrote:
>>> Maybe it could be better if the XSLT stylesheet could read some option  
>>> to generate a reference to >>>another CSS stylesheet (instead of  
>>> xsltforms.css).
>>> What do you think?
>>> --Alain
>>>> Le 10 mai 2020 à 12:41, Steven Pemberton <ste...@cw...> a  
>>>> écrit :
>>>> I have this problem too, and I'm trying to trace how to fix it.  
>>>> The xsltforms css has rules like:
>>>>   xforms-input[xf-bound]:not([xf-notrelevant]) {display: inline}
>>>> which have very high 'specificity'. The CSS1 spec* says:
>>>> * Find all declarations that apply to the element/property in  
>>>> question. Declarations >>>>apply if the selector matches the element  
>>>> in question. If no declarations apply, the >>>>inherited value is  
>>>> used. If there is no inherited value (this is the case for the 'HTML'  
>>>> >>>>element and for properties that do not inherit), the initial  
>>>> value is used.* Sort the declarations by explicit weight:  
>>>> declarations marked '!important' carry more >>>>weight than unmarked  
>>>> (normal) declarations.* Sort by origin: the author's style sheets  
>>>> override the reader's style sheet which >>>>override the UA's default  
>>>> values. An imported style sheet has the same origin as the >>>>style  
>>>> sheet from which it is imported.* Sort by specificity of selector:  
>>>> more specific selectors will override more general >>>>ones. To find  
>>>> the specificity, count the number of ID attributes in the selector  
>>>> (a), the >>>>number of CLASS attributes in the selector (b), and the  
>>>> number of tag names in the >>>>selector (c). Concatenating the three  
>>>> numbers (in a number system with a large base) >>>>gives the  
>>>> specificity.
>>>> "An imported style sheet has the same origin as the style sheet from  
>>>> which it is >>>>imported." means, I think, that the xsltforms.css has  
>>>> the same importance as the style in >>>>the form itself.
>>>> Using !important is in general a poor solution, because it overrides  
>>>> other rules in your >>>>own styling, though it would often work.
>>>> I think, strictly speaking, you have to use the same selector or a  
>>>> more specific one than >>>>in the xsltforms.css
>>>> So to change the display value, you have to use
>>>>   xforms-input[xf-bound]:not([xf-notrelevant]) {display: block}
>>>> I will be experimenting with the xsltforms.css in the coming weeks to  
>>>> see if we can >>>>improve on this situation, because it was easier to  
>>>> do in the previous xsltforms.
>>>> Best wishes,
>>>> Steven
>>>> * The latest CSS spec is harder to read. Check it for yourself at  
>>>> https://www.w3.org/TR/>>>>selectors/#specificity
>>>> A rule of relevance is:
>>>> The specificity of an :is(), :not(), or :has() pseudo-class is  
>>>> replaced by the >>>>specificity of the most specific complex selector  
>>>> in its selector list argument.
>>>>
>>>>
>>>> On Sun, 10 May 2020 09:57:26 +0200, Alain Couthures  
>>>> <ala...@ag...> >>>>wrote:
>>>>> Hello Habs,
>>>>> Sorry, I am not a CSS expert but I think that, in such as situation,  
>>>>> you have >>>>>to add !important in your own CSS rule to override the  
>>>>> default behaviour.
>>>>> Thank you for your feedback!
>>>>> --Alain
>>>>>> Le 22 avril 2020 à 15:03, Habs < ge...@us...> a  
>>>>>> >>>>>>écrit :
>>>>>>
>>>>>>
>>>>>> Hello all :)
>>>>>> Using the new beta from here,  
>>>>>> www.agencexml.com/1.5beta/>>>>>>xsltforms.zip :
>>>>>> xf:input ( xforms-input when using a css inspecting tool )  
>>>>>> >>>>>>defaults to'display:inline'.
>>>>>> I can only seem to style a xf:input as 'display:block' by using an 
>>>>>> inline style on the element
>>>>>> ie. <xf:input ... style="display: block">
>>>>>> and not in a external ref'd style sheet, or a style section within  
>>>>>> >>>>>>'head',from where all other styling on the element appears to  
>>>>>> apply >>>>>>withoutissue.
>>>>>> ie. xforms-input {display: block;}
>>>>>> Is it something I am getting wrong, or a bug, or ?
>>>>>> Thank you and regardsHabs
>>>>>> --- Sent using Alpine/Pine, probably the best MUA ---
>>>>>>
>>>>>> _______________________________________________Xsltforms-support  
>>>>>> mailing lis...@li... 
>>>>>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>

Re: [Xsltforms-support] new beta release testing - possible styling bug - display:block

From: Alain C. <ala...@ag...> - 2020-05-10 19:29:09

<!doctype html>
<html>
 <head> 
  <meta charset="UTF-8"> 
 </head>
 <body>
  <div>
   In previous XSLTForms release, all controls were disabled, with a CSS class, before evaluation to limit flickering when building, especially sensible for switch/case with just one selected case.
  </div>
  <div>
   <br>
  </div>
  <div>
   This release does not use any CSS class but extra attributes which is lighter for Javascript processing.
  </div>
  <div>
   <br>
  </div>
  <div>
    The XSLT transformation is not even required if an author directly uses the generated HTML5 notation. In this case, &lt;xforms-input xf-ref="a"&gt;&lt;xforms-label&gt;A: &lt;/xforms-label&gt;&lt;/xforms-input&gt; should not be displayed until the extra xf-bound attribute is added accordingly.
  </div>
  <div>
   <br>
  </div>
  <div>
   It sounds then impossible to set the default to visible, doesn't it?
  </div>
  <div>
   <br>
  </div>
  <div>
   --Alain
  </div>
  <blockquote type="cite">
   Le 10 mai 2020 à 19:33, Steven Pemberton &lt;ste...@cw...&gt; a écrit&nbsp;: 
   <br>
   <br>
   <div>
    The current stylesheet sets everything to display: none, and then adds the cases when it is not display: none.
   </div>
   <div>
    <br>
   </div>
   <div>
    I think the cure is to do it the other way round: set the default to visible (inline/block) for those elements where this makes sense (like input, but not the actions, model etc.) and then specify explicitly the cases where display is none.
   </div>
   <div>
    <br>
   </div>
   <div>
    In that way, user added CSS (which is only interested in when the elements are visible) can override the default case. The long, specific selectors for display: none will never need to be overridden.
   </div>
   <div>
    <br>
   </div>
   <div>
    Steven
   </div>
   <div>
    <br>
   </div>
   <div>
    On Sun, 10 May 2020 16:06:25 +0200, Alain Couthures &lt;ala...@ag...&gt; wrote: 
    <br>
   </div>
   <br>
   <blockquote>
    <div>
     Maybe it could be better if the XSLT stylesheet could read some option to generate a reference to another CSS stylesheet (instead of xsltforms.css).
    </div>
    <div>
     <br>
    </div>
    <div>
     What do you think?
    </div>
    <div>
     <br>
    </div>
    <div>
     --Alain
    </div>
    <blockquote type="cite">
     Le 10 mai 2020 à 12:41, Steven Pemberton &lt;ste...@cw...&gt; a écrit&nbsp;: 
     <br>
     <br>
     <div>
      I have this problem too, and I'm trying to trace how to fix it.&nbsp;
     </div>
     <div>
      <br>
     </div>
     <div>
      The xsltforms css has 
      <span style="font-family: DejaVu Sans Mono;"> rules like:</span>
     </div>
     <div>
      <br>
     </div>
     <div>
      &nbsp; &nbsp;xforms-input[xf-bound]:not([xf-notrelevant]) {display: inline}
     </div>
     <div>
      <br>
     </div>
     <div>
      which have very high 'specificity'. The CSS1 spec* says:
     </div>
     <div>
      <br>
     </div>
     <div>
      * Find all declarations that apply to the element/property in question. Declarations apply if the selector matches the element in question. If no declarations apply, the inherited value is used. If there is no inherited value (this is the case for the 'HTML' element and for properties that do not inherit), the initial value is used. 
      <br>* Sort the declarations by explicit weight: declarations marked '!important' carry more weight than unmarked (normal) declarations. 
      <br>* Sort by origin: the author's style sheets override the reader's style sheet which override the UA's default values. An imported style sheet has the same origin as the style sheet from which it is imported. 
      <br>* Sort by specificity of selector: more specific selectors will override more general ones. To find the specificity, count the number of ID attributes in the selector (a), the number of CLASS attributes in the selector (b), and the number of tag names in the selector (c). Concatenating the three numbers (in a number system with a large base) gives the specificity.
     </div>
     <div>
      <br>
     </div>
     <div>
      "An imported style sheet has the same origin as the style sheet from which it is imported." means, I think, that the xsltforms.css has the same importance as the style in the form itself.
     </div>
     <div>
      <br>
     </div>
     <div>
      Using !important is in general a poor solution, because it overrides other rules in your own styling, though it would often work.
     </div>
     <div>
      <br>
     </div>
     <div>
      I think, strictly speaking, you have to use the same selector or a more specific one than in the xsltforms.css
     </div>
     <div>
      <br>
     </div>
     <div>
      So to change the display value, you have to use
     </div>
     <div>
      <br>
     </div>
     <div>
      <div>
       &nbsp; &nbsp;xforms-input[xf-bound]:not([xf-notrelevant]) {display: block}
      </div>
      <div>
       <br>
      </div>
      <div>
       I will be experimenting with the xsltforms.css in the coming weeks to see if we can improve on this situation, because it was easier to do in the previous xsltforms.
      </div>
      <div>
       <br>
      </div>
      <div>
       Best wishes,
      </div>
      <div>
       <br>
      </div>
      <div>
       Steven
      </div>
      <div>
       <br>
      </div>
      <div>
       * The latest CSS spec is harder to read. Check it for yourself at https://www.w3.org/TR/selectors/#specificity
      </div>
      <div>
       <br>
      </div>
      <div>
       A rule of relevance is:
      </div>
      <div>
       <br>
      </div>
      <div>
       The specificity of an :is(), :not(), or :has() pseudo-class is replaced by the specificity of the most specific complex selector in its selector list argument.
      </div>
     </div>
     <div>
      <br>
     </div>
     <div>
      <br>
     </div>
     <div>
      <br>
     </div>
     <div>
      On Sun, 10 May 2020 09:57:26 +0200, Alain Couthures &lt;ala...@ag...&gt; wrote: 
      <br>
     </div>
     <br>
     <blockquote>
      <div>
       Hello Habs,
      </div>
      <div>
       <br>
      </div>
      <div>
       Sorry, I am not a CSS expert but I think that, in such as situation, you have to add !important in your own CSS rule to override the default behaviour.
      </div>
      <div>
       <br>
      </div>
      <div>
       Thank you for your feedback!
      </div>
      <div>
       <br>
      </div>
      <div>
       --Alain
      </div>
      <blockquote type="cite">
       <div>
        Le 22 avril 2020 à 15:03, Habs &lt; 
        <a href="mailto:ge...@us...">ge...@us...</a>&gt; a écrit&nbsp;:
       </div>
       <div>
        <br>
       </div>
       <div>
        <br>
       </div>
       <div>
        <br>
       </div>
       <div>
        Hello all :)
       </div>
       <div>
        <br>
       </div>
       <div>
        Using the new beta from here, www.agencexml.com/1.5beta/xsltforms.zip :
       </div>
       <div>
        <br>
       </div>
       <div>
        xf:input ( xforms-input when using a css inspecting tool ) defaults to
       </div>
       <div>
        'display:inline'.
       </div>
       <div>
        <br>
       </div>
       <div>
        I can only seem to style a xf:input as 'display:block' by using an
       </div>
       <div>
        inline style on the element
       </div>
       <div>
        <br>
       </div>
       <div>
        ie. &lt;xf:input ... style="display: block"&gt;
       </div>
       <div>
        <br>
       </div>
       <div>
        and not in a external ref'd style sheet, or a style section within 'head',
       </div>
       <div>
        from where all other styling on the element appears to apply without
       </div>
       <div>
        issue.
       </div>
       <div>
        <br>
       </div>
       <div>
        ie. xforms-input {display: block;}
       </div>
       <div>
        <br>
       </div>
       <div>
        Is it something I am getting wrong, or a bug, or ?
       </div>
       <div>
        <br>
       </div>
       <div>
        Thank you and regards
       </div>
       <div>
        Habs
       </div>
       <div>
        <br>
       </div>
       <div>
        --- Sent using Alpine/Pine, probably the best MUA ---
       </div>
       <div>
        <br>
       </div>
       <div>
        <br>
       </div>
       <div>
        _______________________________________________
       </div>
       <div>
        Xsltforms-support mailing list
       </div>
       <div>
        <a href="mailto:Xsl...@li...">Xsl...@li...</a>
       </div>
       <div>
        <a href="https://lists.sourceforge.net/lists/listinfo/xsltforms-support" target="_blank" rel="noopener">https://lists.sourceforge.net/lists/listinfo/xsltforms-support</a>
       </div>
      </blockquote>
     </blockquote>
     <br>
     <br>
     <br>
    </blockquote>
    <div class="ox-16167616ac-default-style">
     <br>&nbsp;
    </div>
   </blockquote>
   <br>
   <br>
   <br>
  </blockquote>
  <div class="default-style">
   <br>&nbsp;
  </div> 
 </body>
</html>

Re: [Xsltforms-support] new beta release testing - possible styling bug - display:block

From: Steven P. <ste...@cw...> - 2020-05-10 17:34:03

The current stylesheet sets everything to display: none, and then adds the  
cases when it is not display: none.

I think the cure is to do it the other way round: set the default to  
visible (inline/block) for those elements where this makes sense (like  
input, but not the actions, model etc.) and then specify explicitly the  
cases where display is none.

In that way, user added CSS (which is only interested in when the elements  
are visible) can override the default case. The long, specific selectors  
for display: none will never need to be overridden.

Steven

On Sun, 10 May 2020 16:06:25 +0200, Alain Couthures  
<ala...@ag...> wrote:

> Maybe it could be better if the XSLT stylesheet could read some option  
> to generate a reference to another CSS stylesheet >(instead of  
> xsltforms.css).
> What do you think?
> --Alain
>> Le 10 mai 2020 à 12:41, Steven Pemberton <ste...@cw...> a  
>> écrit :
>> I have this problem too, and I'm trying to trace how to fix it.  
>> The xsltforms css has rules like:
>>   xforms-input[xf-bound]:not([xf-notrelevant]) {display: inline}
>> which have very high 'specificity'. The CSS1 spec* says:
>> * Find all declarations that apply to the element/property in question.  
>> Declarations apply if the selector >>matches the element in question.  
>> If no declarations apply, the inherited value is used. If there is no  
>> inherited >>value (this is the case for the 'HTML' element and for  
>> properties that do not inherit), the initial value is >>used.* Sort the  
>> declarations by explicit weight: declarations marked '!important' carry  
>> more weight than unmarked >>(normal) declarations.* Sort by origin: the  
>> author's style sheets override the reader's style sheet which override  
>> the UA's default >>values. An imported style sheet has the same origin  
>> as the style sheet from which it is imported.* Sort by specificity of  
>> selector: more specific selectors will override more general ones. To  
>> find the >>specificity, count the number of ID attributes in the  
>> selector (a), the number of CLASS attributes in the >>selector (b), and  
>> the number of tag names in the selector (c). Concatenating the three  
>> numbers (in a number >>system with a large base) gives the specificity.
>> "An imported style sheet has the same origin as the style sheet from  
>> which it is imported." means, I think, that >>the xsltforms.css has the  
>> same importance as the style in the form itself.
>> Using !important is in general a poor solution, because it overrides  
>> other rules in your own styling, though it >>would often work.
>> I think, strictly speaking, you have to use the same selector or a more  
>> specific one than in the xsltforms.css
>> So to change the display value, you have to use
>>   xforms-input[xf-bound]:not([xf-notrelevant]) {display: block}
>> I will be experimenting with the xsltforms.css in the coming weeks to  
>> see if we can improve on this situation, >>because it was easier to do  
>> in the previous xsltforms.
>> Best wishes,
>> Steven
>> * The latest CSS spec is harder to read. Check it for yourself at  
>> https://www.w3.org/TR/selectors/#specificity
>> A rule of relevance is:
>> The specificity of an :is(), :not(), or :has() pseudo-class is replaced  
>> by the specificity of the most specific >>complex selector in its  
>> selector list argument.
>>
>>
>> On Sun, 10 May 2020 09:57:26 +0200, Alain Couthures  
>> <ala...@ag...> wrote:
>>> Hello Habs,
>>> Sorry, I am not a CSS expert but I think that, in such as situation,  
>>> you have to add !important in >>>your own CSS rule to override the  
>>> default behaviour.
>>> Thank you for your feedback!
>>> --Alain
>>>> Le 22 avril 2020 à 15:03, Habs < ge...@us...> a écrit :
>>>>
>>>>
>>>> Hello all :)
>>>> Using the new beta from here, www.agencexml.com/1.5beta/xsltforms.zip  
>>>> :
>>>> xf:input ( xforms-input when using a css inspecting tool ) defaults to 
>>>> 'display:inline'.
>>>> I can only seem to style a xf:input as 'display:block' by using an 
>>>> inline style on the element
>>>> ie. <xf:input ... style="display: block">
>>>> and not in a external ref'd style sheet, or a style section within  
>>>> 'head',from where all other styling on the element appears to apply  
>>>> withoutissue.
>>>> ie. xforms-input {display: block;}
>>>> Is it something I am getting wrong, or a bug, or ?
>>>> Thank you and regardsHabs
>>>> --- Sent using Alpine/Pine, probably the best MUA ---
>>>>
>>>> _______________________________________________Xsltforms-support  
>>>> mailing lis...@li... 
>>>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>
>>
>>
>

Re: [Xsltforms-support] new beta release testing - possible styling bug - display:block

From: Alain C. <ala...@ag...> - 2020-05-10 14:06:36

<!doctype html>
<html>
 <head> 
  <meta charset="UTF-8"> 
 </head>
 <body>
  <div>
   Maybe it could be better if the XSLT stylesheet could read some option to generate a reference to another CSS stylesheet (instead of xsltforms.css).
  </div>
  <div>
   <br>
  </div>
  <div>
   What do you think?
  </div>
  <div>
   <br>
  </div>
  <div>
   --Alain
  </div>
  <blockquote type="cite">
   Le 10 mai 2020 à 12:41, Steven Pemberton &lt;ste...@cw...&gt; a écrit&nbsp;: 
   <br>
   <br>
   <div>
    I have this problem too, and I'm trying to trace how to fix it.&nbsp;
   </div>
   <div>
    <br>
   </div>
   <div>
    The xsltforms css has 
    <span style="font-family: DejaVu Sans Mono;"> rules like:</span>
   </div>
   <div>
    <br>
   </div>
   <div>
    &nbsp; &nbsp;xforms-input[xf-bound]:not([xf-notrelevant]) {display: inline}
   </div>
   <div>
    <br>
   </div>
   <div>
    which have very high 'specificity'. The CSS1 spec* says:
   </div>
   <div>
    <br>
   </div>
   <div>
    * Find all declarations that apply to the element/property in question. Declarations apply if the selector matches the element in question. If no declarations apply, the inherited value is used. If there is no inherited value (this is the case for the 'HTML' element and for properties that do not inherit), the initial value is used. 
    <br>* Sort the declarations by explicit weight: declarations marked '!important' carry more weight than unmarked (normal) declarations. 
    <br>* Sort by origin: the author's style sheets override the reader's style sheet which override the UA's default values. An imported style sheet has the same origin as the style sheet from which it is imported. 
    <br>* Sort by specificity of selector: more specific selectors will override more general ones. To find the specificity, count the number of ID attributes in the selector (a), the number of CLASS attributes in the selector (b), and the number of tag names in the selector (c). Concatenating the three numbers (in a number system with a large base) gives the specificity.
   </div>
   <div>
    <br>
   </div>
   <div>
    "An imported style sheet has the same origin as the style sheet from which it is imported." means, I think, that the xsltforms.css has the same importance as the style in the form itself.
   </div>
   <div>
    <br>
   </div>
   <div>
    Using !important is in general a poor solution, because it overrides other rules in your own styling, though it would often work.
   </div>
   <div>
    <br>
   </div>
   <div>
    I think, strictly speaking, you have to use the same selector or a more specific one than in the xsltforms.css
   </div>
   <div>
    <br>
   </div>
   <div>
    So to change the display value, you have to use
   </div>
   <div>
    <br>
   </div>
   <div>
    <div>
     &nbsp; &nbsp;xforms-input[xf-bound]:not([xf-notrelevant]) {display: block}
    </div>
    <div>
     <br>
    </div>
    <div>
     I will be experimenting with the xsltforms.css in the coming weeks to see if we can improve on this situation, because it was easier to do in the previous xsltforms.
    </div>
    <div>
     <br>
    </div>
    <div>
     Best wishes,
    </div>
    <div>
     <br>
    </div>
    <div>
     Steven
    </div>
    <div>
     <br>
    </div>
    <div>
     * The latest CSS spec is harder to read. Check it for yourself at https://www.w3.org/TR/selectors/#specificity
    </div>
    <div>
     <br>
    </div>
    <div>
     A rule of relevance is:
    </div>
    <div>
     <br>
    </div>
    <div>
     The specificity of an :is(), :not(), or :has() pseudo-class is replaced by the specificity of the most specific complex selector in its selector list argument.
    </div>
   </div>
   <div>
    <br>
   </div>
   <div>
    <br>
   </div>
   <div>
    <br>
   </div>
   <div>
    On Sun, 10 May 2020 09:57:26 +0200, Alain Couthures &lt;ala...@ag...&gt; wrote: 
    <br>
   </div>
   <br>
   <blockquote>
    <div>
     Hello Habs,
    </div>
    <div>
     <br>
    </div>
    <div>
     Sorry, I am not a CSS expert but I think that, in such as situation, you have to add !important in your own CSS rule to override the default behaviour.
    </div>
    <div>
     <br>
    </div>
    <div>
     Thank you for your feedback!
    </div>
    <div>
     <br>
    </div>
    <div>
     --Alain
    </div>
    <blockquote type="cite">
     <div>
      Le 22 avril 2020 à 15:03, Habs &lt; 
      <a href="mailto:ge...@us...">ge...@us...</a>&gt; a écrit&nbsp;:
     </div>
     <div>
      <br>
     </div>
     <div>
      <br>
     </div>
     <div>
      <br>
     </div>
     <div>
      Hello all :)
     </div>
     <div>
      <br>
     </div>
     <div>
      Using the new beta from here, www.agencexml.com/1.5beta/xsltforms.zip :
     </div>
     <div>
      <br>
     </div>
     <div>
      xf:input ( xforms-input when using a css inspecting tool ) defaults to
     </div>
     <div>
      'display:inline'.
     </div>
     <div>
      <br>
     </div>
     <div>
      I can only seem to style a xf:input as 'display:block' by using an
     </div>
     <div>
      inline style on the element
     </div>
     <div>
      <br>
     </div>
     <div>
      ie. &lt;xf:input ... style="display: block"&gt;
     </div>
     <div>
      <br>
     </div>
     <div>
      and not in a external ref'd style sheet, or a style section within 'head',
     </div>
     <div>
      from where all other styling on the element appears to apply without
     </div>
     <div>
      issue.
     </div>
     <div>
      <br>
     </div>
     <div>
      ie. xforms-input {display: block;}
     </div>
     <div>
      <br>
     </div>
     <div>
      Is it something I am getting wrong, or a bug, or ?
     </div>
     <div>
      <br>
     </div>
     <div>
      Thank you and regards
     </div>
     <div>
      Habs
     </div>
     <div>
      <br>
     </div>
     <div>
      --- Sent using Alpine/Pine, probably the best MUA ---
     </div>
     <div>
      <br>
     </div>
     <div>
      <br>
     </div>
     <div>
      _______________________________________________
     </div>
     <div>
      Xsltforms-support mailing list
     </div>
     <div>
      <a href="mailto:Xsl...@li...">Xsl...@li...</a>
     </div>
     <div>
      <a target="_blank" href="https://lists.sourceforge.net/lists/listinfo/xsltforms-support" rel="noopener">https://lists.sourceforge.net/lists/listinfo/xsltforms-support</a>
     </div>
    </blockquote>
   </blockquote>
   <br>
   <br>
   <br>
  </blockquote>
  <div class="default-style">
   <br>&nbsp;
  </div> 
 </body>
</html>

Re: [Xsltforms-support] new beta release testing - possible styling bug - display:block

From: Steven P. <ste...@cw...> - 2020-05-10 10:41:13

I have this problem too, and I'm trying to trace how to fix it.

The xsltforms css has rules like:

    xforms-input[xf-bound]:not([xf-notrelevant]) {display: inline}

which have very high 'specificity'. The CSS1 spec* says:

* Find all declarations that apply to the element/property in question.  
Declarations apply if the selector matches the element in question. If no  
declarations apply, the inherited value is used. If there is no inherited  
value (this is the case for the 'HTML' element and for properties that do  
not inherit), the initial value is used.
* Sort the declarations by explicit weight: declarations marked  
'!important' carry more weight than unmarked (normal) declarations.
* Sort by origin: the author's style sheets override the reader's style  
sheet which override the UA's default values. An imported style sheet has  
the same origin as the style sheet from which it is imported.
* Sort by specificity of selector: more specific selectors will override  
more general ones. To find the specificity, count the number of ID  
attributes in the selector (a), the number of CLASS attributes in the  
selector (b), and the number of tag names in the selector (c).  
Concatenating the three numbers (in a number system with a large base)  
gives the specificity.

"An imported style sheet has the same origin as the style sheet from which  
it is imported." means, I think, that the xsltforms.css has the same  
importance as the style in the form itself.

Using !important is in general a poor solution, because it overrides other  
rules in your own styling, though it would often work.

I think, strictly speaking, you have to use the same selector or a more  
specific one than in the xsltforms.css

So to change the display value, you have to use

    xforms-input[xf-bound]:not([xf-notrelevant]) {display: block}

I will be experimenting with the xsltforms.css in the coming weeks to see  
if we can improve on this situation, because it was easier to do in the  
previous xsltforms.

Best wishes,

Steven

* The latest CSS spec is harder to read. Check it for yourself at  
https://www.w3.org/TR/selectors/#specificity

A rule of relevance is:

The specificity of an :is(), :not(), or :has() pseudo-class is replaced by  
the specificity of the most specific complex selector in its selector list  
argument.

On Sun, 10 May 2020 09:57:26 +0200, Alain Couthures  
<ala...@ag...> wrote:

> Hello Habs,
> Sorry, I am not a CSS expert but I think that, in such as situation, you  
> have to add !important in your own CSS rule to >override the default  
> behaviour.
> Thank you for your feedback!
> --Alain
>> Le 22 avril 2020 à 15:03, Habs < ge...@us...> a écrit :
>>
>>
>> Hello all :)
>> Using the new beta from here, www.agencexml.com/1.5beta/xsltforms.zip :
>> xf:input ( xforms-input when using a css inspecting tool ) defaults to 
>> 'display:inline'.
>> I can only seem to style a xf:input as 'display:block' by using an 
>> inline style on the element
>> ie. <xf:input ... style="display: block">
>> and not in a external ref'd style sheet, or a style section within  
>> 'head',from where all other styling on the element appears to apply  
>> withoutissue.
>> ie. xforms-input {display: block;}
>> Is it something I am getting wrong, or a bug, or ?
>> Thank you and regardsHabs
>> --- Sent using Alpine/Pine, probably the best MUA ---
>>
>> _______________________________________________Xsltforms-support  
>> mailing lis...@li... 
>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support

Re: [Xsltforms-support] New release: Please give it a try!

From: Alain C. <ala...@ag...> - 2020-05-10 09:28:13

<!doctype html>
<html>
 <head> 
  <meta charset="UTF-8"> 
 </head>
 <body>
  <div>
   I can now run your webserver (using Windows Subsystem for Linux) and I can see that, apparently, only Chromium-based browsers do send 2 requests for xsltforms.xsl.
  </div>
  <div>
   <br>
  </div>
  <div>
   It appears that the first one could be just for accepting text/css and the network debugger does not render the response at all...
  </div>
  <div>
   <br>
  </div>
  <div>
   Chromium is the new Internet Explorer!
  </div>
  <div>
   <br>
  </div>
  <div>
   Alain
  </div>
  <blockquote type="cite">
   <div>
    Le 22 avril 2020 à 05:32, Steven Pemberton &lt;
    <a href="mailto:ste...@cw...">ste...@cw...</a>&gt; a écrit&nbsp;:
   </div>
   <div>
    <br>
   </div>
   <div>
    <br>
   </div>
   <div>
    Watching my webserver, I see that xsltforms.xsl gets loaded twice in quick
   </div>
   <div>
    succession.
   </div>
   <div>
    <br>
   </div>
   <div>
    The xhtml file default-get.xhtml starts like this:
   </div>
   <div>
    <br>
   </div>
   <div>
    &lt;?xml version="1.0" encoding="UTF-8"?&gt;
   </div>
   <div>
    &lt;?xml-stylesheet href="../../xsltforms/xsltforms.xsl" type="text/xsl"?&gt;
   </div>
   <div>
    &lt;?xsltforms-options debug="no"?&gt;
   </div>
   <div>
    &lt;?css-conversion no?&gt;
   </div>
   <div>
    &lt;html xmlns="
    <a href="http://www.w3.org/1999/xhtml" rel="noopener" target="_blank">http://www.w3.org/1999/xhtml"</a>
   </div>
   <div>
    xmlns:ev="
    <a href="http://www.w3.org/2001/xml-events" rel="noopener" target="_blank">http://www.w3.org/2001/xml-events"</a>&gt;
   </div>
   <div>
    &lt;head&gt;
   </div>
   <div>
    <br>
   </div>
   <div>
    Here is the relevant log:
   </div>
   <div>
    <br>
   </div>
   <div>
    GET /forms-new/TestSuite/submission/default-get.xhtml HTTP/1.1
   </div>
   <div>
    =&gt; 200 application/xhtml+xml 2444
   </div>
   <div>
    <br>
   </div>
   <div>
    GET /forms-new/xsltforms/xsltforms.xsl HTTP/1.1
   </div>
   <div>
    =&gt; 200 text/xsl 31149
   </div>
   <div>
    <br>
   </div>
   <div>
    GET /forms-new/xsltforms/xsltforms.xsl HTTP/1.1
   </div>
   <div>
    =&gt; 200 text/xsl 31149
   </div>
   <div>
    <br>
   </div>
   <div>
    GET /forms-new/xsltforms/xsltforms.css HTTP/1.1
   </div>
   <div>
    =&gt; 200 text/css 13000
   </div>
   <div>
    <br>
   </div>
   <div>
    GET /forms-new/TestSuite/test-suite.css HTTP/1.1
   </div>
   <div>
    =&gt; 200 text/css 4359
   </div>
   <div>
    <br>
   </div>
   <div>
    GET /forms-new/xsltforms/xsltforms.js HTTP/1.1
   </div>
   <div>
    =&gt; 200 application/javascript 682649
   </div>
   <div>
    <br>
   </div>
   <div>
    GET /forms-new/xsltforms/config_en.xsl HTTP/1.1
   </div>
   <div>
    =&gt; 200 text/xsl 1524
   </div>
   <div>
    <br>
   </div>
   <div>
    Best wishes,
   </div>
   <div>
    <br>
   </div>
   <div>
    Steven
   </div>
  </blockquote> 
 </body>
</html>

Re: [Xsltforms-support] new beta release testing - possible styling bug - display:block

From: Alain C. <ala...@ag...> - 2020-05-10 08:10:49

<!doctype html>
<html>
 <head> 
  <meta charset="UTF-8"> 
 </head>
 <body>
  <div>
   Hello Habs,
  </div>
  <div>
   <br>
  </div>
  <div>
   Sorry, I am not a CSS expert but I think that, in such as situation, you have to add !important in your own CSS rule to override the default behaviour.
  </div>
  <div>
   <br>
  </div>
  <div>
   Thank you for your feedback!
  </div>
  <div>
   <br>
  </div>
  <div>
   --Alain
  </div>
  <blockquote type="cite">
   <div>
    Le 22 avril 2020 à 15:03, Habs &lt;
    <a href="mailto:ge...@us...">ge...@us...</a>&gt; a écrit&nbsp;:
   </div>
   <div>
    <br>
   </div>
   <div>
    <br>
   </div>
   <div>
    <br>
   </div>
   <div>
    Hello all :)
   </div>
   <div>
    <br>
   </div>
   <div>
    Using the new beta from here, www.agencexml.com/1.5beta/xsltforms.zip :
   </div>
   <div>
    <br>
   </div>
   <div>
    xf:input ( xforms-input when using a css inspecting tool ) defaults to
   </div>
   <div>
    'display:inline'.
   </div>
   <div>
    <br>
   </div>
   <div>
    I can only seem to style a xf:input as 'display:block' by using an
   </div>
   <div>
    inline style on the element
   </div>
   <div>
    <br>
   </div>
   <div>
    ie. &lt;xf:input ... style="display: block"&gt;
   </div>
   <div>
    <br>
   </div>
   <div>
    and not in a external ref'd style sheet, or a style section within 'head',
   </div>
   <div>
    from where all other styling on the element appears to apply without
   </div>
   <div>
    issue.
   </div>
   <div>
    <br>
   </div>
   <div>
    ie. xforms-input {display: block;}
   </div>
   <div>
    <br>
   </div>
   <div>
    Is it something I am getting wrong, or a bug, or ?
   </div>
   <div>
    <br>
   </div>
   <div>
    Thank you and regards
   </div>
   <div>
    Habs
   </div>
   <div>
    <br>
   </div>
   <div>
    --- Sent using Alpine/Pine, probably the best MUA ---
   </div>
   <div>
    <br>
   </div>
   <div>
    <br>
   </div>
   <div>
    _______________________________________________
   </div>
   <div>
    Xsltforms-support mailing list
   </div>
   <div>
    <a href="mailto:Xsl...@li...">Xsl...@li...</a>
   </div>
   <div>
    <a href="https://lists.sourceforge.net/lists/listinfo/xsltforms-support" rel="noopener" target="_blank">https://lists.sourceforge.net/lists/listinfo/xsltforms-support</a>
   </div>
  </blockquote> 
 </body>
</html>

[Xsltforms-support] new beta release testing - possible styling bug - display:block

From: Habs <ge...@us...> - 2020-04-22 13:29:18

Hello all :)

Using the new beta from here, www.agencexml.com/1.5beta/xsltforms.zip :

xf:input ( xforms-input when using a css inspecting tool ) defaults to 
'display:inline'.

I can only seem to style a xf:input as 'display:block' by using an 
inline style on the element

ie. <xf:input ...  style="display: block">

and not in a external ref'd style sheet, or a style section within 'head', 
from where all other styling on the element appears to apply without 
issue.

ie. xforms-input {display: block;}

Is it something I am getting wrong, or a bug, or ?

Thank you and regards
Habs

--- Sent using Alpine/Pine, probably the best MUA ---

Re: [Xsltforms-support] New release: Please give it a try!

From: Steven P. <ste...@cw...> - 2020-04-22 05:12:19

Attachments: xslt-submission-no-resource.png

<submission/> with no resource generates a fault (see image). It should  
dispatch an xforms-submit-error event.

Previous version of XSLTForms didn't generate the event either, but  
instead (incorrectly) did the submission with an empty resource.

Source of example generating the problem:  
http://www.cwi.nl/~steven/tests/no-resource-submission.xhtml

Steven

Re: [Xsltforms-support] New release: Please give it a try!

From: Steven P. <ste...@cw...> - 2020-04-22 03:33:10

Watching my webserver, I see that xsltforms.xsl gets loaded twice in quick  
succession.

The xhtml file default-get.xhtml starts like this:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="../../xsltforms/xsltforms.xsl" type="text/xsl"?>
<?xsltforms-options debug="no"?>
<?css-conversion no?>
<html xmlns="http://www.w3.org/1999/xhtml"
       xmlns:ev="http://www.w3.org/2001/xml-events">
<head>

Here is the relevant log:

GET /forms-new/TestSuite/submission/default-get.xhtml HTTP/1.1
  => 200 application/xhtml+xml 2444

GET /forms-new/xsltforms/xsltforms.xsl HTTP/1.1
  => 200 text/xsl 31149

GET /forms-new/xsltforms/xsltforms.xsl HTTP/1.1
  => 200 text/xsl 31149

GET /forms-new/xsltforms/xsltforms.css HTTP/1.1
  => 200 text/css 13000

GET /forms-new/TestSuite/test-suite.css HTTP/1.1
  => 200 text/css 4359

GET /forms-new/xsltforms/xsltforms.js HTTP/1.1
  => 200 application/javascript 682649

GET /forms-new/xsltforms/config_en.xsl HTTP/1.1
  => 200 text/xsl 1524

Best wishes,

Steven

Re: [Xsltforms-support] New release: Please give it a try!

From: Steven P. <ste...@cw...> - 2020-04-05 21:14:35

Attachments: block.xhtml

With:
<style type="text/css">
.block {display: block}
</style>

<output class="block" ref="p"/>

the output is nevertheless output with display: inline.

Test case attached.

Steven

Re: [Xsltforms-support] New release: Please give it a try!

From: Steven P. <ste...@cw...> - 2020-04-05 18:20:23

Wonderful! It works.

Thanks!

Steven

On Sun, 05 Apr 2020 14:00:15 +0200, Alain Couthures  
<ala...@ag...> wrote:

> Hello Steven,
> Everything was almost already there to support AVT on HTML attributes  
> (typically @class and @style) of XForms controls so I >just had to  
> adjust the sources accordingly.
> Please find the latest beta build at the same location:   
> www.agencexml.com/1.5beta/xsltforms.zip
> Thank you for your feedback!
> --Alain
>> Le 3 avril 2020 à 22:52, Steven Pemberton <ste...@cw...> a  
>> écrit :
>> Am I right in thinking that
>>   <output class="{@foo} value="bar"/>
>> doesn't work yet?
>> (Working to get the testsuite running under the new release).
>> Best wishes,
>> Steven  
>> On Wed, 05 Feb 2020 21:15:57 +0100, Alain Couthures  
>> <ala...@ag...> wrote:
>>> Hello,
>>> Please find a new release for XSLTForms at  
>>> www.agencexml.com/1.5beta/xsltforms.zip
>>> It has not yet been fully tested because a lot of changes have been  
>>> made and you are >>>welcome to locate remaining issues with your own  
>>> forms.
>>> The XSLT part has been reduced to minimal for better performance.  
>>> Instead of parsing the >>>XPath expressions and transforming all the  
>>> XForms elements into HTML elements, it >>>basically just transposes  
>>> the non-HTML elements into sort-of custom elements: xforms:*  
>>> >>>elements become xforms-* elements with xf-* and ev-* attributes.
>>> Have a look with your favorite browser debugger! Actually, authors  
>>> could even prefer to >>>directly write/generate forms with this new  
>>> notation and forget about the XSLT step. You >>>can compare two  
>>> sources for the same form: hello.xml and hello.htm
>>> XSLTForms Javascript classes constructors are obtaining their  
>>> properties directly from >>>xf-* attributes and XPath parsing is then  
>>> performed.
>>> No ids are automatically added as previously.
>>> Extra xf-* attributes and extra xforms-* elements are used to embed  
>>> effective HTML >>>rendering elements, for example, xforms-body or  
>>> xforms-repeat-item while, before, span >>>or div elements where used.
>>> XSLTForms classes for xforms:select and xforms:itemset had to be  
>>> partially rewritten.
>>> SVG support has been basically tested too.
>>> CSS styling is not anymore based on xforms-* classes but on custom  
>>> element names and >>>attribute selectors. For example, the extra  
>>> xf-bound attribute, when present, says that >>>the XForms control is  
>>> bound to a node, eventually a not relevant one, and the extra  
>>> xf->>>notrelevant attribute can, then, be checked...
>>> Thank you for your contribution!
>>> --Alain
>>
>>
>>
>

Re: [Xsltforms-support] New release: Please give it a try!

From: Steven P. <ste...@cw...> - 2020-04-05 15:35:16

So it looks like the testsuite is now working with the new version.

I did create a new driver XForm that is more readable than the old one.

I'll package it all up, and send it to you tomorrow.

Steven


On Wed, 05 Feb 2020 21:15:57 +0100, Alain Couthures  
<ala...@ag...> wrote:

> Hello,
>
> Please find a new release for XSLTForms at  
> www.agencexml.com/1.5beta/xsltforms.zip
>
> It has not yet been fully tested because a lot of changes have been made  
> and you are welcome to locate remaining issues with your own forms.
>
> The XSLT part has been reduced to minimal for better performance.  
> Instead of parsing the XPath expressions and transforming all the XForms  
> >elements into HTML elements, it basically just transposes the non-HTML  
> elements into sort-of custom elements: xforms:* elements become xforms-*  
> >elements with xf-* and ev-* attributes.
>
> Have a look with your favorite browser debugger! Actually, authors could  
> even prefer to directly write/generate forms with this new notation and  
> forget >about the XSLT step. You can compare two sources for the same  
> form: hello.xml and hello.htm
>
> XSLTForms Javascript classes constructors are obtaining their properties  
> directly from xf-* attributes and XPath parsing is then performed.
>
> No ids are automatically added as previously.
>
> Extra xf-* attributes and extra xforms-* elements are used to embed  
> effective HTML rendering elements, for example, xforms-body or  
> xforms-repeat->item while, before, span or div elements where used.
>
> XSLTForms classes for xforms:select and xforms:itemset had to be  
> partially rewritten.
>
> SVG support has been basically tested too.
>
> CSS styling is not anymore based on xforms-* classes but on custom  
> element names and attribute selectors. For example, the extra xf-bound  
> >attribute, when present, says that the XForms control is bound to a  
> node, eventually a not relevant one, and the extra xf-notrelevant  
> attribute can, then, >be checked...
>
> Thank you for your contribution!
>
> --Alain

Re: [Xsltforms-support] New release: Please give it a try!

From: Steven P. <ste...@cw...> - 2020-04-05 15:31:58

So I created a minimal test case, and it worked!

So I went back to the original problem example to see what was different,  
and it worked too!

So there was some glitch in the space-time continuum yesterday, because it  
is now working.

Sorry for the noise!

Steven


On Sun, 05 Apr 2020 14:02:04 +0200, Alain Couthures  
<ala...@ag...> wrote:

> Could you please send me a minimal test case for this issue?
> Thanks!
> --Alain
>> Le 3 avril 2020 à 23:18, Steven Pemberton <ste...@cw...> a  
>> écrit :
>> I'm getting a strange effect:
>> If I run an XForm in an iframe, it's not getting the xforms-ready event. 
>> If I run it in a tab of its own, it does.
>> This is happening over several forms, so I think it is a general  
>> effect, and not dependent on the form.
>> Here is an example.
>> In an iframe:
>> 0 -> Dispatching event xforms-model-construct on <xforms-model id="M"/> 
>> 4 -> Calculate res0 -> Calculate res1 -> Calculate res0 -> Calculate res 
>> 2 -> Calculate pass no0 -> Calculate pass no0 -> Calculate pass no1 ->  
>> Calculate pass no0 -> Calculate pass FAIL2 -> Dispatching event  
>> xforms-model-construct-done on <xforms-model id="M"/>1 -> Dispatching  
>> event xforms-model-construct on <xforms-model  
>> id="xsltforms_model_config"/>1 -> Dispatching event  
>> xforms-model-construct-done on <xforms-model  
>> id="xsltforms_model_config"/>5 -> Dispatching event xforms-enabled on  
>> <xforms-output/>1 -> Dispatching event xforms-enabled on  
>> <xforms-output/>0 -> Dispatching event xforms-enabled on  
>> <xforms-output/>1 -> Dispatching event xforms-enabled on  
>> <xforms-output/>
>> That's all that happens.
>>
>> In a tab:
>> 1 -> Dispatching event go on <xforms-model id="M"/>0 ->  
>> effectiveTarget:true0 -> Captured event go on <XFORMS-MODEL id="M"/>1  
>> -> Setvalue test = 2020-04-03T23:15:15+02:001 -> Setvalue @req =  
>> 2020-04-03T23:15:15+02:000 -> Setvalue @index = 20 -> Dispatching event  
>> xforms-recalculate on <xforms-model id="M"/>0 -> Calculate res  
>> 2020-04-03T23:15:15+02:000 -> Calculate res0 -> Calculate res0 ->  
>> Calculate res1 -> Calculate pass yes0 -> Calculate pass no0 ->  
>> Calculate pass no0 -> Calculate pass no0 -> Calculate pass FAIL0 ->  
>> Dispatching event xforms-revalidate on <xforms-model id="M"/>1 ->  
>> Dispatching event xforms-refresh on <xforms-model id="M"/>1 ->  
>> Dispatching event xforms-enabled on <xforms-output/>0 -> Dispatching  
>> event xforms-optional on <xforms-output/>0 -> Dispatching event  
>> xforms-enabled on <xforms-output/>0 -> Dispatching event  
>> xforms-readonly on <xforms-output/>0 -> Dispatching event xforms-valid  
>> on <xforms-output/>0 -> Dispatching event xforms-value-changed on  
>> <xforms-output/>1 -> Dispatching event xforms-disabled on  
>> <xforms-output class="wrong"/>0 -> Dispatching event xforms-enabled on  
>> <xforms-output/>1 -> Dispatching event xforms-enabled on  
>> <xforms-output/>0 -> Dispatching event xforms-enabled on  
>> <xforms-output/>0 -> Dispatching event xforms-ready on <xforms-model  
>> id="xsltforms_model_config"/>
>> Steven
>>
>> On Wed, 05 Feb 2020 21:15:57 +0100, Alain Couthures  
>> <ala...@ag...> wrote:
>>> Hello,
>>> Please find a new release for XSLTForms at  
>>> www.agencexml.com/1.5beta/xsltforms.zip
>>> It has not yet been fully tested because a lot of changes have been  
>>> made and you are >>>welcome to locate remaining issues with your own  
>>> forms.
>>> The XSLT part has been reduced to minimal for better performance.  
>>> Instead of parsing the >>>XPath expressions and transforming all the  
>>> XForms elements into HTML elements, it >>>basically just transposes  
>>> the non-HTML elements into sort-of custom elements: xforms:*  
>>> >>>elements become xforms-* elements with xf-* and ev-* attributes.
>>> Have a look with your favorite browser debugger! Actually, authors  
>>> could even prefer to >>>directly write/generate forms with this new  
>>> notation and forget about the XSLT step. You >>>can compare two  
>>> sources for the same form: hello.xml and hello.htm
>>> XSLTForms Javascript classes constructors are obtaining their  
>>> properties directly from >>>xf-* attributes and XPath parsing is then  
>>> performed.
>>> No ids are automatically added as previously.
>>> Extra xf-* attributes and extra xforms-* elements are used to embed  
>>> effective HTML >>>rendering elements, for example, xforms-body or  
>>> xforms-repeat-item while, before, span >>>or div elements where used.
>>> XSLTForms classes for xforms:select and xforms:itemset had to be  
>>> partially rewritten.
>>> SVG support has been basically tested too.
>>> CSS styling is not anymore based on xforms-* classes but on custom  
>>> element names and >>>attribute selectors. For example, the extra  
>>> xf-bound attribute, when present, says that >>>the XForms control is  
>>> bound to a node, eventually a not relevant one, and the extra  
>>> xf->>>notrelevant attribute can, then, be checked...
>>> Thank you for your contribution!
>>> --Alain
>>
>>
>>
>

Re: [Xsltforms-support] New release: Please give it a try!

From: Alain C. <ala...@ag...> - 2020-04-05 12:13:40

<!doctype html>
<html>
 <head> 
  <meta charset="UTF-8"> 
 </head>
 <body>
  <div>
   Hello Steven,
  </div>
  <div>
   <br>
  </div>
  <div>
   Everything was almost already there to support AVT on HTML attributes (typically @class and @style) of XForms controls so I just had to adjust the sources accordingly.
  </div>
  <div>
   <br>
  </div>
  <div>
   Please find the latest beta build at the same location:&nbsp;
   <span style="font-size: 13px;"></span>
   <a class="ox-1e2fe28a99-moz-txt-link-abbreviated" href="http://www.agencexml.com/1.5beta/xsltforms.zip" style="font-size: 13px;">www.agencexml.com/1.5beta/xsltforms.zip</a>
   <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
    <br>
   </div>
   <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
    Thank you for your feedback!
   </div>
   <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
    <br>
   </div>
   <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
    --Alain
   </div>
   <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
    <br>
   </div>
  </div>
  <blockquote type="cite">
   Le 3 avril 2020 à 22:52, Steven Pemberton &lt;ste...@cw...&gt; a écrit&nbsp;: 
   <br>
   <br>
   <div>
    Am I right in thinking that
   </div>
   <div>
    <br>
   </div>
   <div>
    &nbsp; &nbsp;&lt;output class="{@foo} value="bar"/&gt;
   </div>
   <div>
    <br>
   </div>
   <div>
    doesn't work yet?
   </div>
   <div>
    <br>
   </div>
   <div>
    (Working to get the testsuite running under the new release).
   </div>
   <div>
    <br>
   </div>
   <div>
    Best wishes,
   </div>
   <div>
    <br>
   </div>
   <div>
    Steven&nbsp;
   </div>
   <div>
    <br>
   </div>
   <div>
    On Wed, 05 Feb 2020 21:15:57 +0100, Alain Couthures &lt;ala...@ag...&gt; wrote: 
    <br>
   </div>
   <br>
   <blockquote>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     Hello,
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     Please find a new release for XSLTForms at 
     <a href="http://www.agencexml.com/1.5beta/xsltforms.zip" class="ox-1e2fe28a99-moz-txt-link-abbreviated">www.agencexml.com/1.5beta/xsltforms.zip</a>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     It has not yet been fully tested because a lot of changes have been made and you are welcome to locate remaining issues with your own forms.
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     The XSLT part has been reduced to minimal for better performance. Instead of parsing the XPath expressions and transforming all the XForms elements into HTML elements, it basically just transposes the non-HTML elements into sort-of custom elements: xforms:* elements become xforms-* elements with xf-* and ev-* attributes.
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     Have a look with your favorite browser debugger! Actually, authors could even prefer to directly write/generate forms with this new notation and forget about the XSLT step. You can compare two sources for the same form: hello.xml and hello.htm
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     XSLTForms Javascript classes constructors are obtaining their properties directly from xf-* attributes and XPath parsing is then performed.
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     No ids are automatically added as previously.
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     Extra xf-* attributes and extra xforms-* elements are used to embed effective HTML rendering elements, for example, xforms-body or xforms-repeat-item while, before, span or div elements where used.
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     XSLTForms classes for xforms:select and xforms:itemset had to be partially rewritten.
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     SVG support has been basically tested too.
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     CSS styling is not anymore based on xforms-* classes but on custom element names and attribute selectors. For example, the extra xf-bound attribute, when present, says that the XForms control is bound to a node, eventually a not relevant one, and the extra xf-notrelevant attribute can, then, be checked...
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     Thank you for your contribution!
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     --Alain
    </div>
   </blockquote>
   <br>
   <br>
   <br>
  </blockquote>
  <div class="default-style">
   <br>&nbsp;
  </div> 
 </body>
</html>

Re: [Xsltforms-support] New release: Please give it a try!

From: Alain C. <ala...@ag...> - 2020-04-05 12:02:15

<!doctype html>
<html>
 <head> 
  <meta charset="UTF-8"> 
 </head>
 <body>
  <div>
   Could you please send me a minimal test case for this issue?
  </div>
  <div>
   <br>
  </div>
  <div>
   Thanks!
  </div>
  <div>
   <br>
  </div>
  <div>
   --Alain
  </div>
  <blockquote type="cite">
   Le 3 avril 2020 à 23:18, Steven Pemberton &lt;ste...@cw...&gt; a écrit&nbsp;: 
   <br>
   <br>
   <div>
    I'm getting a strange effect:
   </div>
   <div>
    <br>
   </div>
   <div>
    If I run an XForm in an iframe, it's not getting the xforms-ready event.
   </div>
   <div>
    If I run it in a tab of its own, it does.
   </div>
   <div>
    <br>
   </div>
   <div>
    This is happening over several forms, so I think it is a general effect, and not dependent on the form.
   </div>
   <div>
    <br>
   </div>
   <div>
    Here is an example.
   </div>
   <div>
    <br>
   </div>
   <div>
    In an iframe:
   </div>
   <div>
    <br>
   </div>
   <div>
    0 -&gt; Dispatching event xforms-model-construct on &lt;xforms-model id="M"/&gt; 
    <br>4 -&gt; Calculate res 
    <br>0 -&gt; Calculate res 
    <br>1 -&gt; Calculate res 
    <br>0 -&gt; Calculate res 
    <br>2 -&gt; Calculate pass no 
    <br>0 -&gt; Calculate pass no 
    <br>0 -&gt; Calculate pass no 
    <br>1 -&gt; Calculate pass no 
    <br>0 -&gt; Calculate pass FAIL 
    <br>2 -&gt; Dispatching event xforms-model-construct-done on &lt;xforms-model id="M"/&gt; 
    <br>1 -&gt; Dispatching event xforms-model-construct on &lt;xforms-model id="xsltforms_model_config"/&gt; 
    <br>1 -&gt; Dispatching event xforms-model-construct-done on &lt;xforms-model id="xsltforms_model_config"/&gt; 
    <br>5 -&gt; Dispatching event xforms-enabled on &lt;xforms-output/&gt; 
    <br>1 -&gt; Dispatching event xforms-enabled on &lt;xforms-output/&gt; 
    <br>0 -&gt; Dispatching event xforms-enabled on &lt;xforms-output/&gt; 
    <br>1 -&gt; Dispatching event xforms-enabled on &lt;xforms-output/&gt;
   </div>
   <div>
    <br>
   </div>
   <div>
    That's all that happens.
   </div>
   <div>
    <br>
   </div>
   <div>
    <br>
   </div>
   <div>
    In a tab:
   </div>
   <div>
    <br>
   </div>
   <div>
    1 -&gt; Dispatching event go on &lt;xforms-model id="M"/&gt; 
    <br>0 -&gt; effectiveTarget:true 
    <br>0 -&gt; Captured event go on &lt;XFORMS-MODEL id="M"/&gt; 
    <br>1 -&gt; Setvalue test = 2020-04-03T23:15:15+02:00 
    <br>1 -&gt; Setvalue @req = 2020-04-03T23:15:15+02:00 
    <br>0 -&gt; Setvalue @index = 2 
    <br>0 -&gt; Dispatching event xforms-recalculate on &lt;xforms-model id="M"/&gt; 
    <br>0 -&gt; Calculate res 2020-04-03T23:15:15+02:00 
    <br>0 -&gt; Calculate res 
    <br>0 -&gt; Calculate res 
    <br>0 -&gt; Calculate res 
    <br>1 -&gt; Calculate pass yes 
    <br>0 -&gt; Calculate pass no 
    <br>0 -&gt; Calculate pass no 
    <br>0 -&gt; Calculate pass no 
    <br>0 -&gt; Calculate pass FAIL 
    <br>0 -&gt; Dispatching event xforms-revalidate on &lt;xforms-model id="M"/&gt; 
    <br>1 -&gt; Dispatching event xforms-refresh on &lt;xforms-model id="M"/&gt; 
    <br>1 -&gt; Dispatching event xforms-enabled on &lt;xforms-output/&gt; 
    <br>0 -&gt; Dispatching event xforms-optional on &lt;xforms-output/&gt; 
    <br>0 -&gt; Dispatching event xforms-enabled on &lt;xforms-output/&gt; 
    <br>0 -&gt; Dispatching event xforms-readonly on &lt;xforms-output/&gt; 
    <br>0 -&gt; Dispatching event xforms-valid on &lt;xforms-output/&gt; 
    <br>0 -&gt; Dispatching event xforms-value-changed on &lt;xforms-output/&gt; 
    <br>1 -&gt; Dispatching event xforms-disabled on &lt;xforms-output class="wrong"/&gt; 
    <br>0 -&gt; Dispatching event xforms-enabled on &lt;xforms-output/&gt; 
    <br>1 -&gt; Dispatching event xforms-enabled on &lt;xforms-output/&gt; 
    <br>0 -&gt; Dispatching event xforms-enabled on &lt;xforms-output/&gt; 
    <br>0 -&gt; Dispatching event xforms-ready on &lt;xforms-model id="xsltforms_model_config"/&gt;
   </div>
   <div>
    <br>
   </div>
   <div>
    Steven 
    <br>
    <br>
    <br>
   </div>
   <div>
    On Wed, 05 Feb 2020 21:15:57 +0100, Alain Couthures &lt;ala...@ag...&gt; wrote: 
    <br>
   </div>
   <br>
   <blockquote>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     Hello,
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     Please find a new release for XSLTForms at 
     <a href="http://www.agencexml.com/1.5beta/xsltforms.zip" class="ox-9aac6c58ba-moz-txt-link-abbreviated">www.agencexml.com/1.5beta/xsltforms.zip</a>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     It has not yet been fully tested because a lot of changes have been made and you are welcome to locate remaining issues with your own forms.
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     The XSLT part has been reduced to minimal for better performance. Instead of parsing the XPath expressions and transforming all the XForms elements into HTML elements, it basically just transposes the non-HTML elements into sort-of custom elements: xforms:* elements become xforms-* elements with xf-* and ev-* attributes.
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     Have a look with your favorite browser debugger! Actually, authors could even prefer to directly write/generate forms with this new notation and forget about the XSLT step. You can compare two sources for the same form: hello.xml and hello.htm
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     XSLTForms Javascript classes constructors are obtaining their properties directly from xf-* attributes and XPath parsing is then performed.
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     No ids are automatically added as previously.
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     Extra xf-* attributes and extra xforms-* elements are used to embed effective HTML rendering elements, for example, xforms-body or xforms-repeat-item while, before, span or div elements where used.
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     XSLTForms classes for xforms:select and xforms:itemset had to be partially rewritten.
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     SVG support has been basically tested too.
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     CSS styling is not anymore based on xforms-* classes but on custom element names and attribute selectors. For example, the extra xf-bound attribute, when present, says that the XForms control is bound to a node, eventually a not relevant one, and the extra xf-notrelevant attribute can, then, be checked...
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     Thank you for your contribution!
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     <br>
    </div>
    <div style="color: #000000; font-family: Arial, Helvetica,; font-size: 13px; font-style: normal; font-weight: 400; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
     --Alain
    </div>
   </blockquote>
   <br>
   <br>
   <br>
  </blockquote>
  <div class="default-style">
   <br>&nbsp;
  </div> 
 </body>
</html>

Re: [Xsltforms-support] New release: Please give it a try!

From: Steven P. <ste...@cw...> - 2020-04-03 21:18:54

I'm getting a strange effect:

If I run an XForm in an iframe, it's not getting the xforms-ready event.
If I run it in a tab of its own, it does.

This is happening over several forms, so I think it is a general effect,  
and not dependent on the form.

Here is an example.

In an iframe:

0 -> Dispatching event xforms-model-construct on <xforms-model id="M"/>
4 -> Calculate res
0 -> Calculate res
1 -> Calculate res
0 -> Calculate res
2 -> Calculate pass no
0 -> Calculate pass no
0 -> Calculate pass no
1 -> Calculate pass no
0 -> Calculate pass FAIL
2 -> Dispatching event xforms-model-construct-done on <xforms-model  
id="M"/>
1 -> Dispatching event xforms-model-construct on <xforms-model  
id="xsltforms_model_config"/>
1 -> Dispatching event xforms-model-construct-done on <xforms-model  
id="xsltforms_model_config"/>
5 -> Dispatching event xforms-enabled on <xforms-output/>
1 -> Dispatching event xforms-enabled on <xforms-output/>
0 -> Dispatching event xforms-enabled on <xforms-output/>
1 -> Dispatching event xforms-enabled on <xforms-output/>

That's all that happens.


In a tab:

1 -> Dispatching event go on <xforms-model id="M"/>
0 -> effectiveTarget:true
0 -> Captured event go on <XFORMS-MODEL id="M"/>
1 -> Setvalue test = 2020-04-03T23:15:15+02:00
1 -> Setvalue @req = 2020-04-03T23:15:15+02:00
0 -> Setvalue @index = 2
0 -> Dispatching event xforms-recalculate on <xforms-model id="M"/>
0 -> Calculate res 2020-04-03T23:15:15+02:00
0 -> Calculate res
0 -> Calculate res
0 -> Calculate res
1 -> Calculate pass yes
0 -> Calculate pass no
0 -> Calculate pass no
0 -> Calculate pass no
0 -> Calculate pass FAIL
0 -> Dispatching event xforms-revalidate on <xforms-model id="M"/>
1 -> Dispatching event xforms-refresh on <xforms-model id="M"/>
1 -> Dispatching event xforms-enabled on <xforms-output/>
0 -> Dispatching event xforms-optional on <xforms-output/>
0 -> Dispatching event xforms-enabled on <xforms-output/>
0 -> Dispatching event xforms-readonly on <xforms-output/>
0 -> Dispatching event xforms-valid on <xforms-output/>
0 -> Dispatching event xforms-value-changed on <xforms-output/>
1 -> Dispatching event xforms-disabled on <xforms-output class="wrong"/>
0 -> Dispatching event xforms-enabled on <xforms-output/>
1 -> Dispatching event xforms-enabled on <xforms-output/>
0 -> Dispatching event xforms-enabled on <xforms-output/>
0 -> Dispatching event xforms-ready on <xforms-model  
id="xsltforms_model_config"/>

Steven


On Wed, 05 Feb 2020 21:15:57 +0100, Alain Couthures  
<ala...@ag...> wrote:

> Hello,
>
> Please find a new release for XSLTForms at  
> www.agencexml.com/1.5beta/xsltforms.zip
>
> It has not yet been fully tested because a lot of changes have been made  
> and you are welcome to locate remaining issues with your own forms.
>
> The XSLT part has been reduced to minimal for better performance.  
> Instead of parsing the XPath expressions and transforming all the XForms  
> >elements into HTML elements, it basically just transposes the non-HTML  
> elements into sort-of custom elements: xforms:* elements become  
> xforms->* elements with xf-* and ev-* attributes.
>
> Have a look with your favorite browser debugger! Actually, authors could  
> even prefer to directly write/generate forms with this new notation and  
> forget >about the XSLT step. You can compare two sources for the same  
> form: hello.xml and hello.htm
>
> XSLTForms Javascript classes constructors are obtaining their properties  
> directly from xf-* attributes and XPath parsing is then performed.
>
> No ids are automatically added as previously.
>
> Extra xf-* attributes and extra xforms-* elements are used to embed  
> effective HTML rendering elements, for example, xforms-body or  
> xforms-repeat->item while, before, span or div elements where used.
>
> XSLTForms classes for xforms:select and xforms:itemset had to be  
> partially rewritten.
>
> SVG support has been basically tested too.
>
> CSS styling is not anymore based on xforms-* classes but on custom  
> element names and attribute selectors. For example, the extra xf-bound  
> >attribute, when present, says that the XForms control is bound to a  
> node, eventually a not relevant one, and the extra xf-notrelevant  
> attribute can, >then, be checked...
>
> Thank you for your contribution!
>
> --Alain

Re: [Xsltforms-support] New release: Please give it a try!

From: Steven P. <ste...@cw...> - 2020-04-03 21:13:49

Am I right in thinking that

    <output class="{@foo} value="bar"/>

doesn't work yet?

(Working to get the testsuite running under the new release).

Best wishes,

Steven

On Wed, 05 Feb 2020 21:15:57 +0100, Alain Couthures  
<ala...@ag...> wrote:

> Hello,
>
> Please find a new release for XSLTForms at  
> www.agencexml.com/1.5beta/xsltforms.zip
>
> It has not yet been fully tested because a lot of changes have been made  
> and you are welcome to locate remaining issues with your own forms.
>
> The XSLT part has been reduced to minimal for better performance.  
> Instead of parsing the XPath expressions and transforming all the XForms  
> >elements into HTML elements, it basically just transposes the non-HTML  
> elements into sort-of custom elements: xforms:* elements become xforms-*  
> >elements with xf-* and ev-* attributes.
>
> Have a look with your favorite browser debugger! Actually, authors could  
> even prefer to directly write/generate forms with this new notation and  
> forget >about the XSLT step. You can compare two sources for the same  
> form: hello.xml and hello.htm
>
> XSLTForms Javascript classes constructors are obtaining their properties  
> directly from xf-* attributes and XPath parsing is then performed.
>
> No ids are automatically added as previously.
>
> Extra xf-* attributes and extra xforms-* elements are used to embed  
> effective HTML rendering elements, for example, xforms-body or  
> xforms-repeat->item while, before, span or div elements where used.
>
> XSLTForms classes for xforms:select and xforms:itemset had to be  
> partially rewritten.
>
> SVG support has been basically tested too.
>
> CSS styling is not anymore based on xforms-* classes but on custom  
> element names and attribute selectors. For example, the extra xf-bound  
> >attribute, when present, says that the XForms control is bound to a  
> node, eventually a not relevant one, and the extra xf-notrelevant  
> attribute can, then, >be checked...
>
> Thank you for your contribution!
>
> --Alain

Re: [Xsltforms-support] Problem with form refresh

From: Tim T. <tim...@gm...> - 2020-03-14 15:07:22

Attachments: form_list_4_minimal_tt.xq

Hi, Alex,

I've tested your form in BaseX using RESTXQ and, after some modifications,
it seems to be working. I haven't used eXist for a while, but the approach
should be similar there. Here's what I changed:

(1) Populate the XForms instance from the database directly. Instead
of <xf:instance
id="my-category-list" src="{$file}" xmlns="" />, do <xf:instance
id="my-category-list" xmlns="" ><data>{$file}</data></xf:instance>.

(2) Define the submission to have @replace="instance" instead of
@replace="all":
<xf:submission id="save-to-local-file" method="post" resource="..."
replace="instance" instance="my-category-list">...</xf:submission>

(3) Remove <xf:reset/> from your xforms-submit-done action. This seems to
reset the instance data to its initial state after each submission.
Therefore, you won't see your updates, even though they are being saved to
the database.

My updated version of your XQuery is attached. (Note that the database
functions are specific to BaseX--for example, update:output is a shortcut
to return the modified data after saving it to the database.) Just let me
know if you have any questions.

Tim

--
Tim A. Thompson
Discovery Metadata Librarian
Yale University Library

On Fri, Mar 13, 2020 at 4:05 AM Alessandro via Xsltforms-support <
xsl...@li...> wrote:

> Hi Tim,
>
> By working refresh, do you mean just clearing data from the form once it
> has been saved?
>
> not exactly, data are loaded into the htlm table of the XForm, rows with
> new data are added or old rows deleted and the refresh should update the
> shown data, loading again into the table what just saved to the xml
> database file.
>
> I have attached the two minimal working files. In my case everything runs
> within exist-db 5.2
> Many thanks
> Alex
> --
> Inviato in modo sicuro con Tutanota. Ottieni la tua mailbox crittografata
> e senza pubblicità:
> https://tutanota.com
>
>
>
>
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>

Re: [Xsltforms-support] Problem with form refresh

From: Alessandro <ca...@tu...> - 2020-03-13 08:05:37

Attachments: archivi_lamina_2.xml form_list_4_minimal.xq

Hi Tim,

> By working refresh, do you mean just clearing data from the form once it has been saved?
>
not exactly, data are loaded into the htlm table of the XForm, rows with new data are added or old rows deleted and the refresh should update the shown data, loading again into the table what just saved to the xml database file.

I have attached the two minimal working files. In my case everything runs within exist-db 5.2
Many thanks 
Alex
--
Inviato in modo sicuro con Tutanota. Ottieni la tua mailbox crittografata e senza pubblicità:
https://tutanota.com <https://tutanota.com/>

Re: [Xsltforms-support] Problem with form refresh

From: Tim T. <tim...@gm...> - 2020-03-12 18:02:20

Hi, Alex,

By working refresh, do you mean just clearing data from the form once it
has been saved? If you could provide a full example (it can be off-list if
you prefer), I'm happy to help test.

Best,
Tim


--
Tim A. Thompson
Discovery Metadata Librarian
Yale University Library



On Thu, Mar 12, 2020 at 12:26 PM Alessandro via Xsltforms-support <
xsl...@li...> wrote:

> Dear all,
> in passing from betterforms to xsltforms, now I have a very nice xsltform
> obtained through an xquery file of the following structure:
>
> xquery version "3.0";
> let $form :=
> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:xf="
> http://www.w3.org/2002/xforms">
> .......
> </html>
> let $xslt-pi := processing-instruction xml-stylesheet {'type="text/xsl"
> href="../xsltforms/xsltforms.xsl"'}
>   return ($xslt-pi,$form)
>
> I use the form for displaying a list inside a table which new rows can be
> added to (or deleted from). Everything works the right way, except that
> after changes have been applied, there's no way of obtaining a working
> refresh of the form (not even by closing and re-starting the browser!). A
> problem that by contrast does not arise with .html files...
>
> As an alternative I have tryed to put the whole xq file code inside an
> Xquery function, in order to call the fanction from within an html file
> which could take advantage of exist-db templating system. But things do not
> work either (I guess it is not possible to create an xsltform inside an
> html file).
>
> It might be this is an issue that should be more properly reported to the
> exist-db mailing list, but for sure with betterforms the refresh was not a
> problem while using .xq files for creating forms.
> Best regards
> Alex
>
> --
> Inviato in modo sicuro con Tutanota. Ottieni la tua mailbox crittografata
> e senza pubblicità:
> https://tutanota.com
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>

97 messages has been excluded from this view by a project administrator.

Flat | Threaded

<< < 1 .. 7 8 9 10 11 .. 109 > >> (Page 9 of 109)