xsltforms-support — XSLTForms support list

[Xsltforms-support] [PATCH] Reworked Dialogs to fix show-hidding problems

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

HI,

OK, i crafted a solution that prevents the
«focus-remaining-in-show-dialog-trigger» problem
from re-opening the same modal-dialog multiple times on [Enter] key
and then not hidding its "surround" modal-panel .

The same solution also solves the (unreported) general problems of
invoking multiple times <xf:show> and <xf:hide> for the same
dialog-ids.


PROBLEM
-------------
The accounting held of opened-dialogs on Dialog.show()/hide() is not correct,
resulting in the "surround"-modal-panel:
a) to not close when all dialogs are hidden, or
b) to close even if more modal-dialogs are left open,
as demonstrated by the test-case xform for multiple modal dialogs:
file 'multipleModalDialogs.xml':
http://pastebin.com/VyTVA3w0

(NOTE that in IE the xf:select controls in the test-xform fail(!) on
initialization,
this must be another problem, since it fails even with the older revision.)


SOLUTION
------------------
This idea is simple,
* On Dialog.show(), depending on the target dialog, we should:
a) ignore it if it is the currently showing top-dialog,
b) or re-order it, if it is a previously opened but overlaped dialog.

* On Dialog.hide() we should just ignore any ids refering to not opened dialogs.


IMPLEMENTATION
-----------------------
>From the solution description it is obvious that
a simple var pointing the currently showing dialog,
updated with the id whenever a new dialog opens,
is not enough,
since when a dialog is closed, we need to know the next top-dialog.

==> Therefore we need to maintain an *ordered* stack-of-opened-dialogs. <==

This stack must be a mathimatical "set", meaning that no dialog should
exist more than once within it,
assuming that a dialog page-element is presented at most once (no cloning).

Also, the z-index would increase on every dialog appearence,
even if the dialog was open before, to cover any overllaping ones.
Eventually, the z-index might increase more times than it decreases.

Therefore, the hide() logic now must now hide the "surround" modal-shade-panel
when the stack is empty,
(instead of when the z-index becomes 0, as was done so far)
and when all dialogs are hidden, it is reset to zero(0).


There was indeed such a dialogs-stack in the code, the Dialog.dialogs[] var,
but it was not maintained correctly, if at all.
In the process, i needed a utility removeArrayItem(array, item) function.


* Patch against rev385, checked mannually against Firefox, Chrom, IE.
http://pastebin.com/HitEG33f

NOTE that i cannot build it,
i have already asked instructions about how to check rewritting-rules
in a previous mail.



I hope this patch gets accepted soon, since it solves a serious
usability BUG on modal-dialogs.


Regards
  Kostis


PS: In my codebase i have also patched the appearence of the modal and
modeless dialogs to use use correct css centering on modern browsers
(not-IE6 that is...).

I'm hoping to wrap it up in a separate patch and submit it in this
mailling list someday.

I believe then it would worth the effort to provide for <xf:message
@level="modeless|ephemeral"> using this reworked Dialog stanza.




On Wed, Apr 14, 2010 at 9:03 PM, Kostis Anagnostopoulos
<ank...@gm...> wrote:
> I think i found the problem.
>
> The problem in these 2 browsers stems from the fact that after the
> dialog get shown due to some show-trigger activation,
> that focused-trigger remains its focus.
> So, when pressing [Enter], the show-trigger control gets activated once more,
> and the var Dialog.depth get increased, although the dialog is already visible.
> I remind that the dialog-surround is hidden when the Dialog.depth var
> becomes zero.
> Eventually, there are not enough dialogs to decrease Dialog.depth to
> hide the dialog-surround div.
>
> Now i have to think of a fix...:-)
>
>
> On Wed, Apr 14, 2010 at 8:31 PM, Kostis Anagnostopoulos
> <ank...@gm...> wrote:
>> Hi again,
>>
>> A show-stfopping bug exists on <xf:dialog> for IE and FF:
>>
>> If after a dialog has been opened,
>> the user presses [Enter],
>> then a <xf:hide>action fails to completely hide the dialog,
>> since the back-shade remains
>>
>> Reported agaisnt FF and IE, rev385.
>> Chrome OK.
>>
>>
>> Regards,
>>  Kostis
>>
>> file: simpleDialogCloseProblem.xml
>> -------------------
>> <?xml version="1.0" encoding="UTF-8"?>
>> <?xml-stylesheet href="xsltforms/xsltforms.xsl" type="text/xsl"?>
>> <?xsltforms-options debug="yes" lang="en"?>
>> <html
>>  xmlns="http://www.w3.org/1999/xhtml"
>>  xmlns:xf="http://www.w3.org/2002/xforms"
>>  xmlns:ev="http://www.w3.org/2001/xml-events"
>>>
>>  <head>
>>  <title>Dialog Closing Problem Instance</title>
>>
>>  <xf:model id="model-main" >
>>  <xf:instance><root/></xf:instance>
>>  </xf:model>
>>
>>  </head>
>>
>>  <body>
>>   <xf:trigger>
>>     <xf:label>Show</xf:label>
>>     <xf:show dialog="dlg1"  ev:event="DOMActivate" />
>>   </xf:trigger>
>>
>>   <xf:dialog id="dlg1" >
>>     <p>In Firefox or IE, press [Enter] before hitting 'OK' and the
>> dialog-shade does not close anymore!</p>
>>     <xf:trigger>
>>       <xf:label>OK</xf:label>
>>       <xf:hide dialog="dlg1" ev:event="DOMActivate" />
>>     </xf:trigger>
>>   </xf:dialog>
>>  </body>
>> </html>
>>
>

[Xsltforms-support] css and xsltforms

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

Good suggestion of Dans to have a wikibook page on this.

I've played around with css quite a bit so will start this page.

I still do not have a perfect solution, but feel I am close for what I want.

-- 
Regards

Stephen Cameron

Data Programmer
Integrated Marine Observing System  (IMOS)
eMarine Information Infrastructure Project
University of Tasmania, Private Bag 21, Hobart, TAS 7001, Australia

Tel: +61 3 6226 8507
Fax: +61 3 6226 2997
Email: ste...@ut...
URL: http://www.imos.org.au/eMII.html

Re: [Xsltforms-support] xf:hide fails to close xf:dialog if [Enter] key has been pressed in between

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

I think i found the problem.

The problem in these 2 browsers stems from the fact that after the
dialog get shown due to some show-trigger activation,
that focused-trigger remains its focus.
So, when pressing [Enter], the show-trigger control gets activated once more,
and the var Dialog.depth get increased, although the dialog is already visible.
I remind that the dialog-surround is hidden when the Dialog.depth var
becomes zero.
Eventually, there are not enough dialogs to decrease Dialog.depth to
hide the dialog-surround div.

Now i have to think of a fix...:-)


On Wed, Apr 14, 2010 at 8:31 PM, Kostis Anagnostopoulos
<ank...@gm...> wrote:
> Hi again,
>
> A show-stfopping bug exists on <xf:dialog> for IE and FF:
>
> If after a dialog has been opened,
> the user presses [Enter],
> then a <xf:hide>action fails to completely hide the dialog,
> since the back-shade remains
>
> Reported agaisnt FF and IE, rev385.
> Chrome OK.
>
>
> Regards,
>  Kostis
>
> file: simpleDialogCloseProblem.xml
> -------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <?xml-stylesheet href="xsltforms/xsltforms.xsl" type="text/xsl"?>
> <?xsltforms-options debug="yes" lang="en"?>
> <html
>  xmlns="http://www.w3.org/1999/xhtml"
>  xmlns:xf="http://www.w3.org/2002/xforms"
>  xmlns:ev="http://www.w3.org/2001/xml-events"
>>
>  <head>
>  <title>Dialog Closing Problem Instance</title>
>
>  <xf:model id="model-main" >
>  <xf:instance><root/></xf:instance>
>  </xf:model>
>
>  </head>
>
>  <body>
>   <xf:trigger>
>     <xf:label>Show</xf:label>
>     <xf:show dialog="dlg1"  ev:event="DOMActivate" />
>   </xf:trigger>
>
>   <xf:dialog id="dlg1" >
>     <p>In Firefox or IE, press [Enter] before hitting 'OK' and the
> dialog-shade does not close anymore!</p>
>     <xf:trigger>
>       <xf:label>OK</xf:label>
>       <xf:hide dialog="dlg1" ev:event="DOMActivate" />
>     </xf:trigger>
>   </xf:dialog>
>  </body>
> </html>
>

[Xsltforms-support] xf:hide fails to close xf:dialog if [Enter] key has been pressed in between

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

Hi again,

A show-stfopping bug exists on <xf:dialog> for IE and FF:

If after a dialog has been opened,
the user presses [Enter],
then a <xf:hide>action fails to completely hide the dialog,
since the back-shade remains

Reported agaisnt FF and IE, rev385.
Chrome OK.


Regards,
  Kostis

file: simpleDialogCloseProblem.xml
-------------------
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="xsltforms/xsltforms.xsl" type="text/xsl"?>
<?xsltforms-options debug="yes" lang="en"?>
<html
 xmlns="http://www.w3.org/1999/xhtml"
 xmlns:xf="http://www.w3.org/2002/xforms"
  xmlns:ev="http://www.w3.org/2001/xml-events"
>
 <head>
 <title>Dialog Closing Problem Instance</title>

  <xf:model id="model-main" >
  <xf:instance><root/></xf:instance>
  </xf:model>

 </head>

 <body>
   <xf:trigger>
     <xf:label>Show</xf:label>
     <xf:show dialog="dlg1"  ev:event="DOMActivate" />
   </xf:trigger>

   <xf:dialog id="dlg1" >
     <p>In Firefox or IE, press [Enter] before hitting 'OK' and the
dialog-shade does not close anymore!</p>
     <xf:trigger>
       <xf:label>OK</xf:label>
       <xf:hide dialog="dlg1" ev:event="DOMActivate" />
     </xf:trigger>
   </xf:dialog>
 </body>
</html>

Re: [Xsltforms-support] [PATCH] @ev:phase attribute on xf:actions

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

Hi,
> I've added the capability to define @ev:phase attributes on xf:actions.
>   
Yes! You have reactivated this since it seems that AJAXForms already 
supported this.

I have not tested it but it sounds without consequences when not used so 
it's good to commit it.
> This patch also include a check of miss-typed phase tokens.
>   
This can be useful. Maybe this kind of check should be added in every 
situation. AJAXForms didn't have any in its Javascript part but in its 
Java part.
Error handling with XSLT is not very easy: a Javascript instruction 
should be generated to display an error message. It means that there 
should be a check template for each element (with a specific @mode...).

Whether full check would alter performance or not, I don't know...

Thank you very much!

-Alain

[Xsltforms-support] Infinite-recursion on xforms-recalculate when model without instance and some control exists

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

Hi,


An empty <xf:model> without some <xf:instance> and xforms controls
*without* bindings
(i.e triggers, output with constant-string XPath values)
causes infinite recusrion on form-loading while dispatching:
xforms-recalculate on <span class="xforms-model" id="xf-model-config"/>

tested against rev385, FF, IE, Chrome.

Regards,
  Kostis


file: controlsAndModelWithoutInstance.xml
-----------------
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="xsltforms/xsltforms.xsl" type="text/xsl"?>
<?xsltforms-options debug="yes" lang="en"?>
<html
 xmlns="http://www.w3.org/1999/xhtml"
 xmlns:xf="http://www.w3.org/2002/xforms"
>
 <head>
  <title>Controls and Model without Instance</title>

   <xf:model id="model-main" >
   </xf:model>

  </head>

  <body>
    <!-- either of the controls below cause infinite recursion in FF and IE. -->
    <xf:output value="'hallo'" />>
    <trigger>
      <xf:label>Hallo</xf:label>
    </trigger>
  </body>
</html>

[Xsltforms-support] Shell script to extract release

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

Here's the shell script I use to extract the latest release from SVN for use.
If there's something better, I'd be pleased to use it.
http://pastie.org/917703

Leigh.

[Xsltforms-support] [PATCH] @ev:phase attribute on xf:actions

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

Hi,

I've added the capability to define @ev:phase attributes on xf:actions.

This patch also include a check of miss-typed phase tokens.
Against rev385 (maintained tabs and indentation on sources)

(unfortunately i could not build it, since make my apache's rewritting
rules might to work)

Regards,
  Kostis

PS:
1) Is this mailling-list the right place to submit patches?
2) Should my patches also include the changes on the final
xsltforms.{js,xsl} files?


file: evPhaseAttr.diff
-------------------------------

Index: src/js/xmlevtmngt/Listener.js.xml
===================================================================
--- src/js/xmlevtmngt/Listener.js.xml   (revision 383)
+++ src/js/xmlevtmngt/Listener.js.xml   (working copy)
@@ -31,6 +31,12 @@
        <![CDATA[
 function Listener(observer, name, phase, handler) {
     phase = phase || "default";
+    if (phase != "default" && phase != "capture") {
+        xforms.error(xforms.defaultModel, "xforms-compute-exception",
+                "Unknown event-phase(" + phase +") for event("
+                + name + ")"+(observer? " on element(" + observer.id
+ ")":"") + "!");
+        return;
+    }
     this.observer = observer;
     this.name = name;
     this.evtName = document.addEventListener? name : "errorupdate";
Index: src/xslt/script/named-templates/listeners.xsl.xml
===================================================================
--- src/xslt/script/named-templates/listeners.xsl.xml	(revision 383)
+++ src/xslt/script/named-templates/listeners.xsl.xml	(working copy)
@@ -47,7 +47,12 @@
 				</xsl:choose>
 				<xsl:text>"),</xsl:text>
 				<xsl:call-template name="toScriptParam"><xsl:with-param name="p"
select="@ev:event"/></xsl:call-template>
-				<xsl:text>,null,function(evt) {run(xf_</xsl:text>
+				<xsl:text>,</xsl:text>
+				<xsl:choose>
+					<xsl:when test="@ev:phase">'<xsl:value-of select="@ev:phase"/>'</xsl:when>
+					<xsl:otherwise>null</xsl:otherwise>
+				</xsl:choose>
+				<xsl:text>,function(evt) {run(xf_</xsl:text>
 				<xsl:variable name="lname2" select="local-name()"/>
 				<xsl:variable name="nsuri" select="namespace-uri()"/>
 				<xsl:value-of select="$lname2"/>

[Xsltforms-support] Add link to wikibook on xsltforms welcome pages

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

Hi Alain,

In order to help xform-authors and to facilitate contributtors to
project's documentation,
it would be good if you added the link to the wiki-books:
  http://en.wikibooks.org/wiki/XSLTForms
on pages:
a) http://www.agencexml.com/xsltforms (since it is the first page on searches)
b) https://sourceforge.net/projects/xsltforms/ (somewhere on project details)

Thank you,
  Kostis

Re: [Xsltforms-support] XForm fail in IE6 fails with comments with I18N characters (and XPath handling problems)

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

Hi,:
> I traced the problem to I18N handling problems to the fact that the
> content of the file  'xsltforms.xsl' and xsltforms.js are both
> ISO-8859-1,
> and the xsl:output@encoding="ISO-8859-1" xslt declaration.
>
> Is there any reason why these files are not in UTF-8 encoding?
>   
xsltforms.xsl been with ISO-8859-1 shouldn't disturb because it doesn't 
contain characters not been in ISO-8859-1.

xsltforms.js isn't explicitly with ISO-8859-1 encoding... A BOM might 
force UTF encoding but, as xsltforms.xsl, it doesn't contain characters 
not been in ISO-8859-1 either...

xsl:output@encoding should, in the contrary, be very sensible to 
non-ISO-8859-1!

Can you please test with xsl:output@encoding="UTF-8" ?

BTW, can you send me a config_gr.xsl file? I already have UTF-8 config 
files which are operational, at least when processed by the Javascript part.

Thanks!

-Alain

Re: [Xsltforms-support] XForm fail in IE6 fails with comments with I18N characters (and XPath handling problems)

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

2010/4/7 Kostis Anagnostopoulos <ank...@gm...>:
> 2 problems:
>
> [...]
>
> 2) In another similar issue in IE (6 & 7, 8 not tested),
> i found problems when XPath handles text containing non-ASCII chars,
> resulting into html-escaped-entities presented into the user.
>
> I can work-arround these issues by avoiding placing I18N text directly
> into XPath expressions,
> and entering them into instance-doc nodes instead.
>
>
> Both problems reported against rev383, IE6 (not tested with IE 7 & 8)
> I apologize for not attempting to investigate when this issue was
> firstly introduced.

Hi,

I traced the problem to I18N handling problems to the fact that the
content of the file  'xsltforms.xsl' and xsltforms.js are both
ISO-8859-1,
and the xsl:output@encoding="ISO-8859-1" xslt declaration.

Is there any reason why these files are not in UTF-8 encoding?

Thansk in Advance,
  Kostis

Is the

[Xsltforms-support] Examples of using a block form layout

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

When each control is on its own line with the label floating to the left we
call these "block forms" since each control uses a block not span CSS
display.  They are often preferred since each line can have it's own help
and hit text.

If you search the XForms cookbook here:

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

for the keyword "block" like this:

http://www.google.com/custom?hl=en&domains=en.wikibooks.org%2Fwiki%2FXForms&q=block&btnG=Search&sitesearch=en.wikibooks.org%2Fwiki%2FXForms

You can find several examples that put the controls inside a div with a
class of "block layout".

Here is an example:

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

I think that we do need a good Wikibook article on how to style forms with
some good examples.

- Dan

-- 
Dan McCreary
Semantic Solutions Architect
syntactica.com
952-460-1674
VOIP: 111@69.199.167.229

Re: [Xsltforms-support] delete attribute strange behavior (Bug)

[Christian M. <chr...@mu...>]

Oh well I have to apologize,
The bug was totally at my end I used duplicate id's in the trigger element

On Sat, Apr 10, 2010 at 10:14 PM, COUTHURES Alain
<ala...@ag...> wrote:
> Hi Christian,
>> It works for all attributes except for those which occur
>> multiple times in the model. That means for an attribute which also is
>> attribute in an other, different element (different name), the script
>> fails when I click the delete button and crashes with
>>
>> "Uncaught undefined"  xsltforms.js:861
>>
> Can you please provide a minimal test case for this bug?
>
> Thanks!
>
> -Alain
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>

[Xsltforms-support] default css rules solution

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

Here is a solution that seems to work as I want.

<html>
    <head>
        <style type="text/css">
            span.control{white-space:nowrap; }
            span.control-label{display:inline-block; width:300px; 
text-align:right;}
        </style>
    </head>
    <body>
        <span class="control">
            <span class="control-label">Label</span>
            <span class="control-input"><input class="textbox" 
type="textbox" value="value1"/></span>
        </span>
        <span class="control">
            <span class="control-label">A Wider Label</span>
            <span class="control-input"><input class="textbox" 
type="textbox" value="value2"/></span>
        </span>
        <span class="control">
            <span class="control-label">A Much Much Much Wider Label</span>
            <span class="control-input"><input class="textbox" 
type="textbox" value="value3"/></span>
        </span>
        <span class="control">
            <span class="control-label">Label</span>
            <span class="control-input"><input class="textbox" 
type="textbox" value="value1"/></span>
        </span>
        <span class="control">
            <span class="control-label">A Wider Label</span>
            <span class="control-input"><input class="textbox" 
type="textbox" value="value2"/></span>
        </span>
        <span class="control">
            <span class="control-label">A Much Much Much Wider Label</span>
            <span class="control-input"><input class="textbox" 
type="textbox" value="value3"/></span>
        </span>
        <span class="control">
            <span class="control-label">Label</span>
            <span class="control-input"><input class="textbox" 
type="textbox" value="value1"/></span>
        </span>
        <span class="control">
            <span class="control-label">A Wider Label</span>
            <span class="control-input"><input class="textbox" 
type="textbox" value="value2"/></span>
        </span>
        <span class="control">
            <span class="control-label">A Much Much Much Wider Label</span>
            <span class="control-input"><input class="textbox" 
type="textbox" value="value3"/></span>
        </span>
    <body>
</html>

Now label and input move together as one and a label is clearly linked 
to an input spatially.




-- 
Regards

Stephen Cameron

Data Programmer
Integrated Marine Observing System  (IMOS)
eMarine Information Infrastructure Project
University of Tasmania, Private Bag 21, Hobart, TAS 7001, Australia

Tel: +61 3 6226 8507
Fax: +61 3 6226 2997
Email: ste...@ut...
URL: http://www.imos.org.au/eMII.html

[Xsltforms-support] css rules

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

Hello,

I'd like to be able to keep an xform label on the same line as its input 
without using  display:table-row;  display:table-cell; which don't seem 
to be universally supported.

I have use the following css selector rules till now.

span.xforms-control > span { display:table; }
span.xforms-control > span > span { display:table-row; }
span.xforms-control > span > span > span { display:table-cell;  }

Basically I'd like to have the xform control generated by xsltforms 
behave as one atomic unit and move to a new line if there is not enough 
space for the whole thing, label and input!

This would make it possible to have two (or more) xform controls fit 
onto one line and adjust correctly if the window in resized.

Has anyone solved this problem?


-- 
Regards

Stephen Cameron

Data Programmer
Integrated Marine Observing System  (IMOS)
eMarine Information Infrastructure Project
University of Tasmania, Private Bag 21, Hobart, TAS 7001, Australia

Tel: +61 3 6226 8507
Fax: +61 3 6226 2997
Email: ste...@ut...
URL: http://www.imos.org.au/eMII.html

Re: [Xsltforms-support] [PATCH] Adding extra XPath functions

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

Hello,

Yes there was a regression about prefixes...

Here is a working example with the latest SVN version:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:xf="http://www.w3.org/2002/xforms"
      xmlns:local="http://example.com/local"
            local:dummy="dummy">
  <head>
    <title>Testing local XPath functions</title>
    <script>
            XPathCoreFunctions['http://example.com/local sample'] =
                new XPathFunction(false, XPathFunction.DEFAULT_NONE, false,
                    function() { return "a test"; } );
    </script>
    <xf:model>
            <xf:instance>
                <dummy xmlns=""/>
            </xf:instance>
    </xf:model>
  </head>
  <body>
    <p>This is <xf:output value="local:sample()" />.</p>
  </body>
 </html>

Thanks!

-Alain
> OK, i worked around it on Firefox!
>
> Just use the default xpath NS when registering functions:
>   http://www.w3.org/2005/xpath-functions
> and invoke it without prefix!
>
>
> Both FF and IE have problem with the time of registration.
> Apart from Chrome, the 'load' event seems to run after init-code has run,
> so the xpath-to-js xsl template fails.
>
> The patch is still needed for IE and Chrome
> if you want to use different NS
> (which does not work on FF...).
>
>
> Note that all browsers work OK:
> * without the patch, and
> * without the extra NS declaration
> as long as any new xpath functions gets registered under the NS:
>   http://www.w3.org/2005/xpath-functions.
>
> This trick allows even for redefinition of existent functions.
>
>
> Happy XPathing!
>   Kostis
>
>
> file: testNewFuncs.xml
> ----------------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <?xml-stylesheet href="xsltforms/xsltforms.xsl" type="text/xsl"?>
> <?xsltforms-options debug="yes"?>
> <html xmlns="http://www.w3.org/1999/xhtml"
>      xmlns:xf="http://www.w3.org/2002/xforms"
>   
>  <head>
>    <title>Testing User-Defined XPath functions</title>
>    <script >
>        XPathCoreFunctions['http://www.w3.org/2005/xpath-functions new-func'] =
>          new XPathFunction(false, XPathFunction.DEFAULT_NONE, false,
>            function() { return "NEW FUNC"; } );
>    </script>
>    <xf:model>
>      <xf:instance>
>        <data xmlns="">HellO </data>
>      </xf:instance>
>    </xf:model>
>  </head>
>  <body>
>    <p><xf:output value="/data" /> to <xf:output value="concat('My ',
> new-func())" />.</p>
>
>  </body>
> </html>
>
> On Fri, Apr 9, 2010 at 8:21 AM, Kostis Anagnostopoulos
> <ank...@gm...> wrote:
>   
>> I was too quick to report "success!"...
>>
>> I tested on different browsers, and
>> * on Chrome it is OK.
>>
>> * On firefox it does not find the correct NS :-(
>> As an aid, i see that the xslt's result root node (the html element)
>> does not contain the 'local' NS.
>> I then tried the dummy attribute workaround but nothing.
>>
>> * On IE7 it does not locate the extra function,
>> although the XPath expression seems OK,
>> and the function's namspace is correct.
>> It seems that the the registration code for the extra function does not work!
>>
>>
>> It needs more work, particularly on firefox....
>>
>>
>> Kostis
>>
>>
>> On Fri, Apr 9, 2010 at 4:00 AM, Kostis Anagnostopoulos
>> <ank...@gm...> wrote:
>>     
>>> Hi David,
>>>
>>> The problem (i think) was that the newer XPath expression parsing templates
>>> (as of rev361)
>>> for each xpath-expression they filled-in the contents of the variable
>>> 'xexprs' with a nodeset
>>> created out of the blue, so it had no NS attached - thus, your
>>> xmlns:local="..."  declaration was lost.
>>>
>>> I solved it just by embeding the <xexprs> nodeset within a node from
>>> the source document,
>>> just by copying the current node.
>>>
>>> Note that I have not tested the patch thorougly,
>>> it just makes your test-case to run ok.
>>> For a quicker setup, you can mannually patch the final 'xsltforms.xsl'
>>> file in line: 197
>>>
>>> Regards
>>>  Kostis
>>>
>>>
>>>
>>> On Tue, Mar 30, 2010 at 9:26 PM, David Cato <ot...@cr...> wrote:
>>>       
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <?xml-stylesheet href="xsltforms/xsltforms.xsl" type="text/xsl"?>
>>>> <html xmlns="http://www.w3.org/1999/xhtml"
>>>>      xmlns:xf="http://www.w3.org/2002/xforms"
>>>>      xmlns:local="http://example.com/local">
>>>>  <head>
>>>>    <title>Testing local XPath functions</title>
>>>>    <script>
>>>>      window.addEventListener('load', function() {
>>>>        XPathCoreFunctions['http://example.com/local sample'] =
>>>>          new XPathFunction(false, XPathFunction.DEFAULT_NONE, false,
>>>>            function() { return "a test"; } );
>>>>      }, false);
>>>>    </script>
>>>>    <xf:model>
>>>>      <xf:instance>
>>>>        <data xmlns="">
>>>>          <PersonGivenName/>
>>>>        </data>
>>>>      </xf:instance>
>>>>    </xf:model>
>>>>  </head>
>>>>  <body>
>>>>    <p>This is <xf:output value="local:sample()" />.</p>
>>>>    <p>Type your first name in the input box. <br/>
>>>>       If you are running XForms, the output should be displayed in the output area.</p>
>>>>    <xf:input ref="PersonGivenName" incremental="true">
>>>>      <xf:label>Please enter your first name: </xf:label>
>>>>    </xf:input>
>>>>    <br />
>>>>    <xf:output value="concat('Hello ', PersonGivenName, '. We hope you like XForms!')">
>>>>      <xf:label>Output: </xf:label>
>>>>    </xf:output>
>>>>  </body>
>>>> </html>
>>>>
>>>>         
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Xsltforms-support mailing list
>> Xsl...@li...
>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>     

Re: [Xsltforms-support] delete attribute strange behavior (Bug)

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

Hi Christian,
> It works for all attributes except for those which occur
> multiple times in the model. That means for an attribute which also is
> attribute in an other, different element (different name), the script
> fails when I click the delete button and crashes with
>
> "Uncaught undefined"  xsltforms.js:861
>   
Can you please provide a minimal test case for this bug?

Thanks!

-Alain

Re: [Xsltforms-support] [PATCH] Adding extra XPath functions

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

OK, i worked around it on Firefox!

Just use the default xpath NS when registering functions:
  http://www.w3.org/2005/xpath-functions
and invoke it without prefix!


Both FF and IE have problem with the time of registration.
Apart from Chrome, the 'load' event seems to run after init-code has run,
so the xpath-to-js xsl template fails.

The patch is still needed for IE and Chrome
if you want to use different NS
(which does not work on FF...).


Note that all browsers work OK:
* without the patch, and
* without the extra NS declaration
as long as any new xpath functions gets registered under the NS:
  http://www.w3.org/2005/xpath-functions.

This trick allows even for redefinition of existent functions.


Happy XPathing!
  Kostis


file: testNewFuncs.xml
----------------------------
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="xsltforms/xsltforms.xsl" type="text/xsl"?>
<?xsltforms-options debug="yes"?>
<html xmlns="http://www.w3.org/1999/xhtml"
     xmlns:xf="http://www.w3.org/2002/xforms"
>
 <head>
   <title>Testing User-Defined XPath functions</title>
   <script >
       XPathCoreFunctions['http://www.w3.org/2005/xpath-functions new-func'] =
         new XPathFunction(false, XPathFunction.DEFAULT_NONE, false,
           function() { return "NEW FUNC"; } );
   </script>
   <xf:model>
     <xf:instance>
       <data xmlns="">HellO </data>
     </xf:instance>
   </xf:model>
 </head>
 <body>
   <p><xf:output value="/data" /> to <xf:output value="concat('My ',
new-func())" />.</p>

 </body>
</html>

On Fri, Apr 9, 2010 at 8:21 AM, Kostis Anagnostopoulos
<ank...@gm...> wrote:
> I was too quick to report "success!"...
>
> I tested on different browsers, and
> * on Chrome it is OK.
>
> * On firefox it does not find the correct NS :-(
> As an aid, i see that the xslt's result root node (the html element)
> does not contain the 'local' NS.
> I then tried the dummy attribute workaround but nothing.
>
> * On IE7 it does not locate the extra function,
> although the XPath expression seems OK,
> and the function's namspace is correct.
> It seems that the the registration code for the extra function does not work!
>
>
> It needs more work, particularly on firefox....
>
>
> Kostis
>
>
> On Fri, Apr 9, 2010 at 4:00 AM, Kostis Anagnostopoulos
> <ank...@gm...> wrote:
>> Hi David,
>>
>> The problem (i think) was that the newer XPath expression parsing templates
>> (as of rev361)
>> for each xpath-expression they filled-in the contents of the variable
>> 'xexprs' with a nodeset
>> created out of the blue, so it had no NS attached - thus, your
>> xmlns:local="..."  declaration was lost.
>>
>> I solved it just by embeding the <xexprs> nodeset within a node from
>> the source document,
>> just by copying the current node.
>>
>> Note that I have not tested the patch thorougly,
>> it just makes your test-case to run ok.
>> For a quicker setup, you can mannually patch the final 'xsltforms.xsl'
>> file in line: 197
>>
>> Regards
>>  Kostis
>>
>>
>>
>> On Tue, Mar 30, 2010 at 9:26 PM, David Cato <ot...@cr...> wrote:
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <?xml-stylesheet href="xsltforms/xsltforms.xsl" type="text/xsl"?>
>>> <html xmlns="http://www.w3.org/1999/xhtml"
>>>      xmlns:xf="http://www.w3.org/2002/xforms"
>>>      xmlns:local="http://example.com/local">
>>>  <head>
>>>    <title>Testing local XPath functions</title>
>>>    <script>
>>>      window.addEventListener('load', function() {
>>>        XPathCoreFunctions['http://example.com/local sample'] =
>>>          new XPathFunction(false, XPathFunction.DEFAULT_NONE, false,
>>>            function() { return "a test"; } );
>>>      }, false);
>>>    </script>
>>>    <xf:model>
>>>      <xf:instance>
>>>        <data xmlns="">
>>>          <PersonGivenName/>
>>>        </data>
>>>      </xf:instance>
>>>    </xf:model>
>>>  </head>
>>>  <body>
>>>    <p>This is <xf:output value="local:sample()" />.</p>
>>>    <p>Type your first name in the input box. <br/>
>>>       If you are running XForms, the output should be displayed in the output area.</p>
>>>    <xf:input ref="PersonGivenName" incremental="true">
>>>      <xf:label>Please enter your first name: </xf:label>
>>>    </xf:input>
>>>    <br />
>>>    <xf:output value="concat('Hello ', PersonGivenName, '. We hope you like XForms!')">
>>>      <xf:label>Output: </xf:label>
>>>    </xf:output>
>>>  </body>
>>> </html>
>>>
>>
>

[Xsltforms-support] delete attribute strange behavior (Bug)

[Christian M. <chr...@mu...>]

Hi
I have an xform generated with xslt from an schema and I experience a
strange beheaviour (Bug) with the delete element.

<xf:trigger ref=".[index('N10000N10000N10AC1N10C45')]/@rgkmax" id="./@rgkmax">
  <xf:label>del</xf:label>
 <xf:delete ev:event="DOMActivate" nodeset="@rgkmax" context=".."/>
 </xf:trigger>

This action deletes an attribute from the context node inside a repeat
element. It works for all attributes except for those which occur
multiple times in the model. That means for an attribute which also is
attribute in an other, different element (different name), the script
fails when I click the delete button and crashes with

"Uncaught undefined"  xsltforms.js:861

I use revision 360

I guess that the relative resolving of the attribute xpath fails

cheers

[Xsltforms-support] insert bug?

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

I've notice that the following will insert a node at the origin if it 
cannot find a valid nodeset.

                    <xf:insert 
nodeset="instance('inst_data')//aatams:surgery/aatams:project_person_ref/aatams:project_person" 
origin="instance('inst_project_person')/gml:featureMember/aatams:project_person[@gml:id=instance('inst_subfeatures')/project_person_id]"/>

This adds a 'project_person' after the first and only child of the 
instance if there is nothing found by 
nodeset="instance('inst_data')//aatams:surgery/aatams:project_person_ref/aatams:project_person".

I can send a test case if needed.

Maybe that is correct behaviour?





-- 
Regards

Stephen Cameron

Data Programmer
Integrated Marine Observing System  (IMOS)
eMarine Information Infrastructure Project
University of Tasmania, Private Bag 21, Hobart, TAS 7001, Australia

Tel: +61 3 6226 8507
Fax: +61 3 6226 2997
Email: ste...@ut...
URL: http://www.imos.org.au/eMII.html

Re: [Xsltforms-support] [PATCH] Adding extra XPath functions

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

I was too quick to report "success!"...

I tested on different browsers, and
* on Chrome it is OK.

* On firefox it does not find the correct NS :-(
As an aid, i see that the xslt's result root node (the html element)
does not contain the 'local' NS.
I then tried the dummy attribute workaround but nothing.

* On IE7 it does not locate the extra function,
although the XPath expression seems OK,
and the function's namspace is correct.
It seems that the the registration code for the extra function does not work!


It needs more work, particularly on firefox....


Kostis


On Fri, Apr 9, 2010 at 4:00 AM, Kostis Anagnostopoulos
<ank...@gm...> wrote:
> Hi David,
>
> The problem (i think) was that the newer XPath expression parsing templates
> (as of rev361)
> for each xpath-expression they filled-in the contents of the variable
> 'xexprs' with a nodeset
> created out of the blue, so it had no NS attached - thus, your
> xmlns:local="..."  declaration was lost.
>
> I solved it just by embeding the <xexprs> nodeset within a node from
> the source document,
> just by copying the current node.
>
> Note that I have not tested the patch thorougly,
> it just makes your test-case to run ok.
> For a quicker setup, you can mannually patch the final 'xsltforms.xsl'
> file in line: 197
>
> Regards
>  Kostis
>
>
>
> On Tue, Mar 30, 2010 at 9:26 PM, David Cato <ot...@cr...> wrote:
>> <?xml version="1.0" encoding="UTF-8"?>
>> <?xml-stylesheet href="xsltforms/xsltforms.xsl" type="text/xsl"?>
>> <html xmlns="http://www.w3.org/1999/xhtml"
>>      xmlns:xf="http://www.w3.org/2002/xforms"
>>      xmlns:local="http://example.com/local">
>>  <head>
>>    <title>Testing local XPath functions</title>
>>    <script>
>>      window.addEventListener('load', function() {
>>        XPathCoreFunctions['http://example.com/local sample'] =
>>          new XPathFunction(false, XPathFunction.DEFAULT_NONE, false,
>>            function() { return "a test"; } );
>>      }, false);
>>    </script>
>>    <xf:model>
>>      <xf:instance>
>>        <data xmlns="">
>>          <PersonGivenName/>
>>        </data>
>>      </xf:instance>
>>    </xf:model>
>>  </head>
>>  <body>
>>    <p>This is <xf:output value="local:sample()" />.</p>
>>    <p>Type your first name in the input box. <br/>
>>       If you are running XForms, the output should be displayed in the output area.</p>
>>    <xf:input ref="PersonGivenName" incremental="true">
>>      <xf:label>Please enter your first name: </xf:label>
>>    </xf:input>
>>    <br />
>>    <xf:output value="concat('Hello ', PersonGivenName, '. We hope you like XForms!')">
>>      <xf:label>Output: </xf:label>
>>    </xf:output>
>>  </body>
>> </html>
>>
>

[Xsltforms-support] [PATCH] Adding extra XPath functions

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

Hi David,

The problem (i think) was that the newer XPath expression parsing templates
(as of rev361)
for each xpath-expression they filled-in the contents of the variable
'xexprs' with a nodeset
created out of the blue, so it had no NS attached - thus, your
xmlns:local="..."  declaration was lost.

I solved it just by embeding the <xexprs> nodeset within a node from
the source document,
just by copying the current node.

Note that I have not tested the patch thorougly,
it just makes your test-case to run ok.
For a quicker setup, you can mannually patch the final 'xsltforms.xsl'
file in line: 197

Regards
  Kostis



On Tue, Mar 30, 2010 at 9:26 PM, David Cato <ot...@cr...> wrote:
> <?xml version="1.0" encoding="UTF-8"?>
> <?xml-stylesheet href="xsltforms/xsltforms.xsl" type="text/xsl"?>
> <html xmlns="http://www.w3.org/1999/xhtml"
>      xmlns:xf="http://www.w3.org/2002/xforms"
>      xmlns:local="http://example.com/local">
>  <head>
>    <title>Testing local XPath functions</title>
>    <script>
>      window.addEventListener('load', function() {
>        XPathCoreFunctions['http://example.com/local sample'] =
>          new XPathFunction(false, XPathFunction.DEFAULT_NONE, false,
>            function() { return "a test"; } );
>      }, false);
>    </script>
>    <xf:model>
>      <xf:instance>
>        <data xmlns="">
>          <PersonGivenName/>
>        </data>
>      </xf:instance>
>    </xf:model>
>  </head>
>  <body>
>    <p>This is <xf:output value="local:sample()" />.</p>
>    <p>Type your first name in the input box. <br/>
>       If you are running XForms, the output should be displayed in the output area.</p>
>    <xf:input ref="PersonGivenName" incremental="true">
>      <xf:label>Please enter your first name: </xf:label>
>    </xf:input>
>    <br />
>    <xf:output value="concat('Hello ', PersonGivenName, '. We hope you like XForms!')">
>      <xf:label>Output: </xf:label>
>    </xf:output>
>  </body>
> </html>
>

Re: [Xsltforms-support] [PATCH] No usefull message for non-existent bind-ids

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

I reworked a little the patch to make xsltforms more conformant to the
specs (see test-suit 4.5.1.a2),
by making the 2 changes to Binding.evaluate() and
XFElement.evaluateBinding() functions:

1) On binding-error, the engine now always dispatches the
'xforms-binding-exception' to the affected element,
and afterwards, it sends the same event to main-model with the
gathered-error-message,
ONLY when DebugMode=true and when on Refreshing phase, that is,
xforms.building=true.

2) Moved the non-existent bind-ID check from Binding.evaluate() up
into the new XFElement.evaluateBinding() function,
therefore:
  a) the affecting element is known, so the binding-ex event can be
sent to it, and
  b) there is no longer the hypothetical problem i was afraid of
uneccessary screaming on XFActions with bad binds, or so...


So i (think i) solved my note (a) and part of note (e) (regarding
xforms specs) of my previous post.
Yet i now have to add a new "note":

f) In this last patch, in order for Binding.evaluate() to signify back
to XFElement.evaluateBinding() that the bind-ID was not found,
it returns 'null'.
If for any other reason the result of its normal operation returns 'null',
then the XFElements would issue a binding-ex with "non-existent
bind-ID" message.
But i think returning 'null' is an error condition anyway.


Attached an enhanced test to check for the new events on the affected elements.

Patch against rev383.
Tested (mannualy), OK on firefox 3, chrome 4, ie6.

Regards,
  Kostis


On Thu, Apr 8, 2010 at 9:06 PM, Kostis Anagnostopoulos
<ank...@gm...> wrote:
> Hi,
>
> I implemented the most part of the changes i suggested on this thread
> and the development process with xsltforms is now much smoother!
>
> With the patch i attach, it is now possible to explicitely detect
> 2 types of binding-errors and produce 'xform-binding-exception':
> 1) Any empty or missing @bind attributes on XFElements
>    (XFControl, XFGroup, XFItem, XFItemset, XFLabel, XFRepeat, AJXTree)
> 2) Any bad @bind IDREF attributes refering to non-existent xf:bind element IDs.
>
> The 'xforms-binding-exception' gets thrown
> I) either once, during xform-refresh phase, listing all binding-errors,
> II) or afterwards, on each error specifically as it is met.
>
> Patch against rev383.
>
>
> PATCH DESCRIPTION
> ---------------------------------
> I added on the 'xforms' global var the member-variable:
>
>    bindErrMsgs : [],           // binding-error messages gathered during refreshing
>
> This array gets updated with any binding errors detected while
> (xforms.building = true).
>
> At the end of xforms.refresh(), a 'xforms-binding-exception' is thrown
> targeted on the default-model
> with all these gathered errors, and then the array-var is cleared.
>
>
> The code performing the error-gathering check happens,
> * for the empty-bindings, inside the new function:
>
>    XFElement.evaluateBinding(binding, ctx)
>
> * for the non-existent bind-IDs, inside the pre-existing function
> (as demonstrated by my previous patch):
>
>    Binding.evaluate(ctx, depsNodes, depsElements)
>
>
> On binding-errors detected during non-building phase, the exception is
> thrown directly
> from within the above 2 functions, targeted on the affecting binding's element.
>
>
> I was carefull enough on the patch to preserve tab-stops and formatting.
>
> Finally, i fiddled i little with css on div#statusPanel to prepare it
> for longer pre-formated error-messages,
> by specifying min-width and min-height instead of fixed frame size.
>
>
>
> NOTES:
> ------------
> Issues to be considered regarding improvements on the patch are the follwoing:
>
> a) Whether the Binding.evaluate() is the correct place to perform the
> check for non-existent bind-IDs.
> ** Does it  improperly scream with searches returning null targets on
> xf:actions?, as i tried to explain in my previous email here?
> ** Should check be moved above on call-stack so the err-msg contain
> affecting's element id (apart from the bad bind-ID)?
>
> b) Did i use the xforms.error() function correctly?
> ** Specifically, is the 1st argument on all invocation sites always valid?
> ** Has the xforms.defaultModel always a value?  What happens when it does not?
>
> c) Should we also apply the error-gathering on XFCoreElement descedant
> binding evaluations?
> (XFInstance, XFSubmision, XFAction, etc)
>
> d) Detect more binding-error types, i.e. null search results for
> binding target objects on repeats, etc.
>
> e) How does this patch behave with respect to xforms-1.1 test-suite?
> Due to insufficient permissions on my wortkplace's computer i couldn't
> build and test the xsltforms from sources,
> therefore i tested the patch-changes on my xsltforms.js mannually, directly.
> I hope everything works as i described above.
> If there is interest, i can send a patch against /trunk/build/xsltforms.js
>
>
> I tested the patch against the previous 2 xforms i have already
> attached on this thread,
> namely 'emptyBindings.xml', and 'nonExistentBindId.xml' and
> the updated test xform 'textBindingsErrors.xml' i attached here,
> and with a rather complicated xform i'm currenty working on,
> and i found no problems.
>
>
> i hope it weren't all these too pedantic...
> Regards,
>  Kostis
>
>
>
>
> On Thu, Apr 8, 2010 at 3:57 AM, Kostis Anagnostopoulos
> <ank...@gm...> wrote:
>> After searching through the specs, i realized that my patch in
>> function Binding.evaluate()
>> would case the engine to scream
>> even for non-existent bidnings on actions, which it is not correct(!),
>> according to Xforms.1.1-chapter 4.7, see:
>> * http://www.w3.org/TR/xforms11/#idref-resolve
>> * http://www.agencexml.com/xforms-tests/testsuite/XForms1.1/Edition1/Chapt04/4.7/4.7.a.xhtml
>>
>> Nevertheless, the problem is very annoying when building xforms
>> because is difficult to debug typos,
>> particularly when merging from different forms.
>>
>> The proper behavior would be to issue 'xforms-binding-exceptions', asd
>> spec'ed by XForms1.1 chapter 4.5.1
>>
>>
>> Additionaly i found that there is another category of annoying
>> fail-to-report binding problems.
>> These are when a 'bind', 'ref', 'nodeset' and 'value' IDERF attributes
>> are themselfs the empty-string ('') or absent altogether.
>> These problems cannot be detected from within Binding.evaluate() since
>> there is no binding object to begin with!
>>
>> The problem is demonstrated with the 'emptyBindings.xml' xforms below.
>>
>>
>>
>> Ideally, i would like to have a solution that gathers all these errors
>> and reports them at once on model-construction with a single
>> xforms-binding-exception,
>> or afterwards, with some alert with a descriptive messages
>> facilitating pin-pointing the error
>> (since i have managed to build a formthat these errors were not
>> detected from the start)
>>
>> Yet this check cannnot happen inside Binding.evaluate() but must be
>> separate for
>> * XFControl,
>> * XFCoreElement, and
>> * XFElement.
>>
>>
>>
>> In a summury, i'm thinking that it may be necessary to add 3
>> functions, one per each super-class,
>> namely "evaluateBindings()" with different arguments each (3, 1, 1 respectively)
>> and they would perform the various sanity checks before invoking
>> this.binding.evaluate().
>> Their behavior on these 2 error categories would be different
>> depending on whether the model has been constructed or not.
>>
>> Am i thinking along the correct lines, Alain?
>>
>> Regards,
>>  Kostis
>>
>>
>>
>> file: emptyBindings.xml
>> -------------------
>> <?xml version="1.0" encoding="UTF-8"?>
>> <?xml-stylesheet href="xsltforms/xsltforms.xsl" encoding="UTF-8"
>> type="text/xsl"?>
>> <html
>>  xmlns="http://www.w3.org/1999/xhtml"
>>  xmlns:xf="http://www.w3.org/2002/xforms"
>>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>  xsi:schemaLocation="
>>     http://www.w3.org/2002/xforms
>> http://www.w3.org/MarkUp/Forms/2007/XForms-11-Schema.xsd
>> "
>>>
>>  <head>
>>    <title>Control with Empty bind-id</title>
>>    <xf:model>
>>      <xf:instance>
>>       <root />
>>      </xf:instance>
>>
>>      <xf:bind id="bind-with-no-nodeset"/>
>>    </xf:model>
>>  </head>
>>
>>  <body>
>>    <xf:output id="should-not-fail-1" bind="bind-with-no-nodeset" />
>>    <xf:repeat id="should-not-fail-3" bind="bind-with-no-nodeset" />
>>    <xf:select1 id="should-not-fail-2" ref="/." >
>>      <xf:itemset bind="bind-with-no-nodeset" />
>>    </xf:select1>
>>
>>    The control's empty-binding below fail with un-helpful err-messages.
>>    <xf:output />
>>    <xf:output ref="" />
>>    <xf:output value="" />
>>
>>    <xf:select1  >
>>      <xf:itemset />
>>    </xf:select1>
>>    <xf:select1  >
>>      <xf:itemset nodeset="" />
>>    </xf:select1>
>>
>>    <xf:select  >
>>      <xf:itemset />
>>    </xf:select>
>>    <xf:select  >
>>      <xf:itemset nodeset="" />
>>    </xf:select>
>>
>>    <xf:repeat />
>>    <xf:repeat nodeset="" />
>>
>>    <xf:group />
>>    <xf:group ref="" />
>>
>>    <xf:label />
>>    <xf:label ref="" />
>>
>>  </body>
>> </html>
>>
>>
>>
>> On Thu, Apr 8, 2010 at 1:05 AM, Kostis Anagnostopoulos
>> <ank...@gm...> wrote:
>>> When a control's 'bind' attrribute refers to an xf:bind that does not exist,
>>> the javascript just fails with Null-Pointer message on browser console
>>> instead of reporting the bad bind-id.
>>>
>>> Reported against rev383, all browsers.
>>>
>>> The simple xform below reproduces the problem, and
>>> the following patch just issues a useful alert-window for each
>>> non-existent bind-id:
>>>
>>> Regards,
>>>  Kostis
>>>
>>> file: nonExistentBindId.xml:
>>> ------------------
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <?xml-stylesheet href="xsltforms/xsltforms.xsl" encoding="UTF-8"
>>> type="text/xsl"?>
>>> <html
>>>  xmlns="http://www.w3.org/1999/xhtml"
>>>  xmlns:xf="http://www.w3.org/2002/xforms"
>>>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>  xsi:schemaLocation="
>>>     http://www.w3.org/2002/xforms
>>> http://www.w3.org/MarkUp/Forms/2007/XForms-11-Schema.xsd
>>> "
>>>>
>>>  <head>
>>>    <title>Control with non-existent bind-id</title>
>>>
>>>  </head>
>>>
>>>  <body>
>>>    The output control's binding below silently fails
>>>    (with an un-helpful null-pointer err-message visible only on the
>>> browser's console).
>>>    <xf:output bind="missing-bind-id" />
>>>    <xf:output bind="missing-bind-id2" />
>>>  </body>
>>> </html>
>>>
>>>
>>> file: nonExistentBindId.diff
>>> ----------------
>>> Index: src/js/main/Binding.js.xml
>>> ===================================================================
>>> --- src/js/main/Binding.js.xml  (revision 383)
>>> +++ src/js/main/Binding.js.xml  (working copy)
>>> @@ -48,7 +48,14 @@
>>>        var result = null;
>>>        if (this.bind) {
>>>                if (typeof this.bind == "string") {
>>> -                       this.bind = $(this.bind).xfElement;
>>> +                       var idel = $(this.bind);
>>> +                       if (!idel) {
>>> +                               alert("Non-Existent bind-id: "+this.bind);
>>> +
>>> +                               // Do not fail here, to search for more missing ids.
>>> +                               return '';
>>> +                       }
>>> +                       this.bind = idel.xfElement;
>>>                }
>>>                result = this.bind.nodes;
>>>                copyArray(this.bind.depsNodes, depsNodes);
>>>
>>
>

Re: [Xsltforms-support] Question about saving forms data directly into subversion

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

On Tue, Apr 6, 2010 at 10:24 PM, COUTHURES Alain
<ala...@ag...> wrote:
> Hello Dan,
>> Is there any way to also send login credentials (login/password) in
>> the HTTP header using this approach?
> xf:header sub-element for xf:submission is not yet supported by
> XSLTForms but it shouldn't be very difficult to add this.
>
> When would you like to experiment this ?

The sooner the better.

Currently i'm using the 'SOAPAction' as a workaround to pass any
out-of-band infos to backend servers.
A working xf:header element would be really usefull for me.

Thanks in Advance,
  Kostis

Re: [Xsltforms-support] [PATCH] No usefull message for non-existent bind-ids

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

Hi,

I implemented the most part of the changes i suggested on this thread
and the development process with xsltforms is now much smoother!

With the patch i attach, it is now possible to explicitely detect
2 types of binding-errors and produce 'xform-binding-exception':
1) Any empty or missing @bind attributes on XFElements
    (XFControl, XFGroup, XFItem, XFItemset, XFLabel, XFRepeat, AJXTree)
2) Any bad @bind IDREF attributes refering to non-existent xf:bind element IDs.

The 'xforms-binding-exception' gets thrown
I) either once, during xform-refresh phase, listing all binding-errors,
II) or afterwards, on each error specifically as it is met.

Patch against rev383.


PATCH DESCRIPTION
---------------------------------
I added on the 'xforms' global var the member-variable:

    bindErrMsgs : [],		// binding-error messages gathered during refreshing

This array gets updated with any binding errors detected while
(xforms.building = true).

At the end of xforms.refresh(), a 'xforms-binding-exception' is thrown
targeted on the default-model
with all these gathered errors, and then the array-var is cleared.


The code performing the error-gathering check happens,
* for the empty-bindings, inside the new function:

    XFElement.evaluateBinding(binding, ctx)

* for the non-existent bind-IDs, inside the pre-existing function
(as demonstrated by my previous patch):

    Binding.evaluate(ctx, depsNodes, depsElements)


On binding-errors detected during non-building phase, the exception is
thrown directly
from within the above 2 functions, targeted on the affecting binding's element.


I was carefull enough on the patch to preserve tab-stops and formatting.

Finally, i fiddled i little with css on div#statusPanel to prepare it
for longer pre-formated error-messages,
by specifying min-width and min-height instead of fixed frame size.



NOTES:
------------
Issues to be considered regarding improvements on the patch are the follwoing:

a) Whether the Binding.evaluate() is the correct place to perform the
check for non-existent bind-IDs.
** Does it  improperly scream with searches returning null targets on
xf:actions?, as i tried to explain in my previous email here?
** Should check be moved above on call-stack so the err-msg contain
affecting's element id (apart from the bad bind-ID)?

b) Did i use the xforms.error() function correctly?
** Specifically, is the 1st argument on all invocation sites always valid?
** Has the xforms.defaultModel always a value?  What happens when it does not?

c) Should we also apply the error-gathering on XFCoreElement descedant
binding evaluations?
(XFInstance, XFSubmision, XFAction, etc)

d) Detect more binding-error types, i.e. null search results for
binding target objects on repeats, etc.

e) How does this patch behave with respect to xforms-1.1 test-suite?
Due to insufficient permissions on my wortkplace's computer i couldn't
build and test the xsltforms from sources,
therefore i tested the patch-changes on my xsltforms.js mannually, directly.
I hope everything works as i described above.
If there is interest, i can send a patch against /trunk/build/xsltforms.js


I tested the patch against the previous 2 xforms i have already
attached on this thread,
namely 'emptyBindings.xml', and 'nonExistentBindId.xml' and
the updated test xform 'textBindingsErrors.xml' i attached here,
and with a rather complicated xform i'm currenty working on,
and i found no problems.


i hope it weren't all these too pedantic...
Regards,
  Kostis




On Thu, Apr 8, 2010 at 3:57 AM, Kostis Anagnostopoulos
<ank...@gm...> wrote:
> After searching through the specs, i realized that my patch in
> function Binding.evaluate()
> would case the engine to scream
> even for non-existent bidnings on actions, which it is not correct(!),
> according to Xforms.1.1-chapter 4.7, see:
> * http://www.w3.org/TR/xforms11/#idref-resolve
> * http://www.agencexml.com/xforms-tests/testsuite/XForms1.1/Edition1/Chapt04/4.7/4.7.a.xhtml
>
> Nevertheless, the problem is very annoying when building xforms
> because is difficult to debug typos,
> particularly when merging from different forms.
>
> The proper behavior would be to issue 'xforms-binding-exceptions', asd
> spec'ed by XForms1.1 chapter 4.5.1
>
>
> Additionaly i found that there is another category of annoying
> fail-to-report binding problems.
> These are when a 'bind', 'ref', 'nodeset' and 'value' IDERF attributes
> are themselfs the empty-string ('') or absent altogether.
> These problems cannot be detected from within Binding.evaluate() since
> there is no binding object to begin with!
>
> The problem is demonstrated with the 'emptyBindings.xml' xforms below.
>
>
>
> Ideally, i would like to have a solution that gathers all these errors
> and reports them at once on model-construction with a single
> xforms-binding-exception,
> or afterwards, with some alert with a descriptive messages
> facilitating pin-pointing the error
> (since i have managed to build a formthat these errors were not
> detected from the start)
>
> Yet this check cannnot happen inside Binding.evaluate() but must be
> separate for
> * XFControl,
> * XFCoreElement, and
> * XFElement.
>
>
>
> In a summury, i'm thinking that it may be necessary to add 3
> functions, one per each super-class,
> namely "evaluateBindings()" with different arguments each (3, 1, 1 respectively)
> and they would perform the various sanity checks before invoking
> this.binding.evaluate().
> Their behavior on these 2 error categories would be different
> depending on whether the model has been constructed or not.
>
> Am i thinking along the correct lines, Alain?
>
> Regards,
>  Kostis
>
>
>
> file: emptyBindings.xml
> -------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <?xml-stylesheet href="xsltforms/xsltforms.xsl" encoding="UTF-8"
> type="text/xsl"?>
> <html
>  xmlns="http://www.w3.org/1999/xhtml"
>  xmlns:xf="http://www.w3.org/2002/xforms"
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>  xsi:schemaLocation="
>     http://www.w3.org/2002/xforms
> http://www.w3.org/MarkUp/Forms/2007/XForms-11-Schema.xsd
> "
>>
>  <head>
>    <title>Control with Empty bind-id</title>
>    <xf:model>
>      <xf:instance>
>       <root />
>      </xf:instance>
>
>      <xf:bind id="bind-with-no-nodeset"/>
>    </xf:model>
>  </head>
>
>  <body>
>    <xf:output id="should-not-fail-1" bind="bind-with-no-nodeset" />
>    <xf:repeat id="should-not-fail-3" bind="bind-with-no-nodeset" />
>    <xf:select1 id="should-not-fail-2" ref="/." >
>      <xf:itemset bind="bind-with-no-nodeset" />
>    </xf:select1>
>
>    The control's empty-binding below fail with un-helpful err-messages.
>    <xf:output />
>    <xf:output ref="" />
>    <xf:output value="" />
>
>    <xf:select1  >
>      <xf:itemset />
>    </xf:select1>
>    <xf:select1  >
>      <xf:itemset nodeset="" />
>    </xf:select1>
>
>    <xf:select  >
>      <xf:itemset />
>    </xf:select>
>    <xf:select  >
>      <xf:itemset nodeset="" />
>    </xf:select>
>
>    <xf:repeat />
>    <xf:repeat nodeset="" />
>
>    <xf:group />
>    <xf:group ref="" />
>
>    <xf:label />
>    <xf:label ref="" />
>
>  </body>
> </html>
>
>
>
> On Thu, Apr 8, 2010 at 1:05 AM, Kostis Anagnostopoulos
> <ank...@gm...> wrote:
>> When a control's 'bind' attrribute refers to an xf:bind that does not exist,
>> the javascript just fails with Null-Pointer message on browser console
>> instead of reporting the bad bind-id.
>>
>> Reported against rev383, all browsers.
>>
>> The simple xform below reproduces the problem, and
>> the following patch just issues a useful alert-window for each
>> non-existent bind-id:
>>
>> Regards,
>>  Kostis
>>
>> file: nonExistentBindId.xml:
>> ------------------
>> <?xml version="1.0" encoding="UTF-8"?>
>> <?xml-stylesheet href="xsltforms/xsltforms.xsl" encoding="UTF-8"
>> type="text/xsl"?>
>> <html
>>  xmlns="http://www.w3.org/1999/xhtml"
>>  xmlns:xf="http://www.w3.org/2002/xforms"
>>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>  xsi:schemaLocation="
>>     http://www.w3.org/2002/xforms
>> http://www.w3.org/MarkUp/Forms/2007/XForms-11-Schema.xsd
>> "
>>>
>>  <head>
>>    <title>Control with non-existent bind-id</title>
>>
>>  </head>
>>
>>  <body>
>>    The output control's binding below silently fails
>>    (with an un-helpful null-pointer err-message visible only on the
>> browser's console).
>>    <xf:output bind="missing-bind-id" />
>>    <xf:output bind="missing-bind-id2" />
>>  </body>
>> </html>
>>
>>
>> file: nonExistentBindId.diff
>> ----------------
>> Index: src/js/main/Binding.js.xml
>> ===================================================================
>> --- src/js/main/Binding.js.xml  (revision 383)
>> +++ src/js/main/Binding.js.xml  (working copy)
>> @@ -48,7 +48,14 @@
>>        var result = null;
>>        if (this.bind) {
>>                if (typeof this.bind == "string") {
>> -                       this.bind = $(this.bind).xfElement;
>> +                       var idel = $(this.bind);
>> +                       if (!idel) {
>> +                               alert("Non-Existent bind-id: "+this.bind);
>> +
>> +                               // Do not fail here, to search for more missing ids.
>> +                               return '';
>> +                       }
>> +                       this.bind = idel.xfElement;
>>                }
>>                result = this.bind.nodes;
>>                copyArray(this.bind.depsNodes, depsNodes);
>>
>