Basic XForms observations

Hi,

I have my first XForms test working - great!
Now I need some guidance please on what I am seeing

1) Can the Submit button be a regular browser submit button

2a) Can the (only) Submit button be activated when in one of the form
fields by hitting return
(it seems to be getting eaten by the javascript which makes a call to
/xforms-server)
2b) On a related note, I can't tab to the submit button, as I would
with a regular xhtml form
In other words, there seems to be no way with the keyboard to send the
form to the server.
I realize that AJAX means we can have a more interactive (granular)
form, but at some point you still need to say "I'm done"

3) Is there a way to get the cursor to be in the first (well, a
specific) data field when the form is first displayed.

I have a view pipeline that most pages can go through.
Regular Model/View pageflows give a 'data' input to this pipeline.
If I do an Action/Result pageflow, even though what is being passed is
the output of my action pipeline, it arrives at my view pipeline as an
'instance'
4) Is this something I just live with? Are there any performance
implications?
(Meanwhile I have a pre pipeline which just takes that instance and
calls the real pipeline where it arrives as an input)

The url that the user arrives at after submitting the form (the result)
has my pagename but then appended is a great long string starting
%24instance=
5) Can I stop this happening

I checked the forms generated for accessibility (at cynthia says).
They pass.
I confess I was surprised because they don't have tabindex and they
don't have accesskey.
6) Can these be added?
Automatically ;-)

I noticed that most of the examples use tables for laying out the forms.
Since I started my current business five years ago, I have never used
tables for layout, always css.
Looking at the sources, it seems that they are coming out as tables
because you are sending them in as tables.
And if I don't put tables into my forms, I don't get tables.
OK so far.
But if you look at what gets delivered to the browser there is still at
least one table - I haven't done anything yet to cause it to become
visible but it seems to be for error messages.
7a) Is there a way (to select) to stop doing this?
We win business because of our belief/ability in achieving such
"purity" so this could weaken our message.
Furthermore, and probably more important for the site user, this table
is coming up in a completely separate part of the page, so may never be
visible or associated with the correct form (that is, my form is inside
a div, which is inside one or more further divs, and this table is
outside all the divs).
7b) Can this be fixed?
I saw comments this morning about xforms-to-ajax-xhtml.xsl being
reimplemented in java, so that means the answer to these questions (and
similar) would no longer be "you can customize the transform" ;-)

Oh wait, just checking the page in the browser again, and I realize
that the form element has been wrapped around all my content (so the
browser has body/form/div/div/p/label even though coming out of my
final pipeline I have
xhtml:body/xhtml:div/xhtml:div/xforms:group/xhtml:p/xforms:input and so
I would be expecting body/div/div/forms/p/label).
7c) Is this really the intent (how would it work with two forms on the
page?)?
And this of course explains (not that I'd looked into it yet) why my
css is not formatting the form, since the css depends on the (expected)
element sequence.

My final point is about non-forms
I noticed early on that a page that does not involve xforms is still
generated with references to all the javascript files.
This can really slow access to the site for the first time (probably
the home page, with a high probability that the user won't hang around
to explore the site).
8) Can the epilogue be made more aware on this?

Thanks for all your help
(One day I hope to ask a difficult technical xforms question, like
about repeats, but first I have to get these simple global things out
the way ;-)
Best regards
Colin




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Colin O'Brien wrote:
 > Hi,
 >
 > I have my first XForms test working - great!
 > Now I need some guidance please on what I am seeing
 >
 > 1) Can the Submit button be a regular browser submit button

Yes, that's the default. What do you see?

 > 2a) Can the (only) Submit button be activated when in one of the
 > form fields by hitting return (it seems to be getting eaten by the
 > javascript which makes a call to /xforms-server)

That's in the works: the DOMActivate event is supposed to be sent when
pressing "enter" in an input field, but there is a bug currently. This
should be fixed soon. As soon as that works, you can put an event
handler in place for DOMActivate and perform an xforms:send action.

 > 2b) On a related note, I can't tab to the submit button, as I would
 > with a regular xhtml form In other words, there seems to be no way
 > with the keyboard to send the form to the server.  I realize that
 > AJAX means we can have a more interactive (granular) form, but at
 > some point you still need to say "I'm done"

I do not see this problem. I can tab to submit buttons just fine. This
may be related to your problem #1 above.

 > 3) Is there a way to get the cursor to be in the first (well, a
 > specific) data field when the form is first displayed.

This in general should be possible with the xforms:setfocus
action. Upon initialization however, that's something to try.

 > I have a view pipeline that most pages can go through.  Regular
 > Model/View pageflows give a 'data' input to this pipeline.  If I do
 > an Action/Result pageflow, even though what is being passed is the
 > output of my action pipeline, it arrives at my view pipeline as an
 > 'instance'

 > 4) Is this something I just live with? Are there any performance
 > implications?
 > (Meanwhile I have a pre pipeline which just takes that instance and
 > calls the real pipeline where it arrives as an input)

We need a little more details to answer here.

 > The url that the user arrives at after submitting the form (the result)
 > has my pagename but then appended is a great long string starting
 > %24instance=

 > 5) Can I stop this happening

Are you sure you are not using the Classic XForms engine? Do you have
"xforms" attribute on <page> elements in your page flow? You are
describing a symptom of that.

 > I checked the forms generated for accessibility (at cynthia says).
 > They pass.
 > I confess I was surprised because they don't have tabindex and they
 > don't have accesskey.
 > 6) Can these be added?
 > Automatically ;-)

We should at least make sure we implement the suggested behavior
described here:

http://www.w3.org/TR/2005/PER-xforms-20051006/index-all.html#evt-next

I entered an RFE to track this:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=304270&group_id=168&atid=350210

I don't know if that translates into generating tabindex automatically
for all elements.

 > I noticed that most of the examples use tables for laying out the forms.
 > Since I started my current business five years ago, I have never used
 > tables for layout, always css.
 > Looking at the sources, it seems that they are coming out as tables
 > because you are sending them in as tables.
 > And if I don't put tables into my forms, I don't get tables.
 > OK so far.
 > But if you look at what gets delivered to the browser there is still at
 > least one table - I haven't done anything yet to cause it to become
 > visible but it seems to be for error messages.

 > 7a) Is there a way (to select) to stop doing this?
 > We win business because of our belief/ability in achieving such "purity"
 > so this could weaken our message.

Again a symptom of XForms Classic ;-)

 > Furthermore, and probably more important for the site user, this table
 > is coming up in a completely separate part of the page, so may never be
 > visible or associated with the correct form (that is, my form is inside
 > a div, which is inside one or more further divs, and this table is
 > outside all the divs).

At this point you should not see this table with XForms NG.

 > 7b) Can this be fixed?
 > I saw comments this morning about xforms-to-ajax-xhtml.xsl being
 > reimplemented in java, so that means the answer to these questions (and
 > similar) would no longer be "you can customize the transform" ;-)
 >
 > Oh wait, just checking the page in the browser again, and I realize that
 > the form element has been wrapped around all my content (so the browser
 > has body/form/div/div/p/label even though coming out of my final
 > pipeline I have
 > xhtml:body/xhtml:div/xhtml:div/xforms:group/xhtml:p/xforms:input and so
 > I would be expecting body/div/div/forms/p/label).
 > 7c) Is this really the intent (how would it work with two forms on the
 > page?)?

Yes, for now this is intentional. With XForms, this is not like with
(X)HTML the concept of multiple forms, really. You can place form
controls anywhere on a page, and be bound to completely different
XForms instances in any order you want. Then you control what is "a
form" by submitting a particular XForms instance or a subset thereof,
not based on the geographical positioning of form elements on the
page. But we still need an HTML form element on the page so that
XForms submission with replace="all" can be implemented, and the
easiest and most predictable way we found was to just put that element
at the top level. I think that as per HTML form controls have to be
within a <form> element, so the only other option would be to detect
the youngest common ancestor to all HTML form controls. But that's a
little harder to do.

 > And this of course explains (not that I'd looked into it yet) why my css
 > is not formatting the form, since the css depends on the (expected)
 > element sequence.
 >
 > My final point is about non-forms
 > I noticed early on that a page that does not involve xforms is still
 > generated with references to all the javascript files.
 > This can really slow access to the site for the first time (probably the
 > home page, with a high probability that the user won't hang around to
 > explore the site).
 > 8) Can the epilogue be made more aware on this?

I think it would be a "nice to have", yes. I just entered an RFE:

http://forge.objectweb.org/tracker/index.php?func=detail&aid=304269&group_id=168&atid=350210

 > Thanks for all your help
 > (One day I hope to ask a difficult technical xforms question, like about
 > repeats, but first I have to get these simple global things out the
way ;-)
 > Best regards
 > Colin

-Erik




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi Erik

thanks for the quick response.

It seemed a lot of what I was seeing was because I was getting into  
Classic?

I started by adding the files for the XForms Sandbox to my project.
It is flagged as NG.
When I had that code working, I took out the upload and added a couple  
of text fields, and changed the server to use a pipeline to save it to  
file and reformat it to pass to my view to return a non-form page.
So all I know about XForms and OPS is from that one example.

I will have to investigate how/when it might have become classic'fied  
and get back to you.


On Nov 9, 2005, at 3:09 PM, Erik Bruchez wrote:

> Colin O'Brien wrote:
> > Hi,
> >
> > I have my first XForms test working - great!
> > Now I need some guidance please on what I am seeing
> >
> > 1) Can the Submit button be a regular browser submit button
>
> Yes, that's the default. What do you see?

Same as I see on all your examples.
It's button-like, but not what I see on other sites, not platform  
native.
Hard to describe it so I will have to get you a screenshot.

I am using Firefox 1.07 on Mac OSX as my test browser.
And I am up to date with the nightly builds.

>
> > 2a) Can the (only) Submit button be activated when in one of the
> > form fields by hitting return (it seems to be getting eaten by the
> > javascript which makes a call to /xforms-server)
>
> That's in the works: the DOMActivate event is supposed to be sent when
> pressing "enter" in an input field, but there is a bug currently. This
> should be fixed soon. As soon as that works, you can put an event
> handler in place for DOMActivate and perform an xforms:send action.

OK - sounds good. OK - I will look into that. I will send you more info separately. That sounds like the right idea, thanks. Ah, I see the problem. I was thinking (from my simple case) that the  
xforms:group would be the boundary but of course you can have more than  
one, and they may be in the same form or different ones. I will have to  
see if I can find a different answer, as for our css it is problematic  
to be losing context in this way. We could maybe restore context by  
adding a div (and you could use the same div to identify where the form  
starts of course - this means you are no longer pure XForms, but since  
we need to anticipate that the form will be translated to (X)HTML  
aren't we working with artificial constraints anyway).
As someone who thinks the highest priority now might be to finish the  
documentation (because there are already so many great new  
features/details), before completing the code, I will have a hard time  
arguing against this. I also know that if I sit down with a client to  
do a demo of their nice new website and it takes forever to appear on  
screen because of this, then we might not be able to spread OPS as fast  
as we would like.

Thanks again
best regards
Colin




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Colin O'Brien wrote:

 >> Yes, that's the default. What do you see?
 >
 > Same as I see on all your examples.
 > It's button-like, but not what I see on other sites, not platform
native.
 > Hard to describe it so I will have to get you a screenshot.
 >
 > I am using Firefox 1.07 on Mac OSX as my test browser.
 > And I am up to date with the nightly builds.

We are using the HTML <button> element, which is rendered natively by
the browser. On Windows with FF 1.5 RC and IE 6, it looks exactly like
a reglar <submit>.

 >> > And this of course explains (not that I'd looked into it yet) why
 >> my  css
 >> > is not formatting the form, since the css depends on the (expected)
 >> > element sequence.
 >
 >
 > Ah, I see the problem. I was thinking (from my simple case) that the
 > xforms:group would be the boundary but of course you can have more than
 > one, and they may be in the same form or different ones.

And they can be nested completely arbitrarily. The can serve as
containers for controls you want to show or hide, or simply as a
convenience for shortening "ref" attributes.

 > I will have to see if I can find a different answer, as for our css
 > it is problematic to be losing context in this way. We could maybe
 > restore context by adding a div (and you could use the same div to
 > identify where the form starts of course - this means you are no
 > longer pure XForms, but since we need to anticipate that the form
 > will be translated to (X)HTML aren't we working with artificial
 > constraints anyway).

Is this a real problem for CSS? If you use the descendant selector
(the default one). E.g.:

   body div { ... }

matches <div> in:

<body>
   <div>

but also in:

<body>
   <form>
     <div>

 > As someone who thinks the highest priority now might be to finish
 > the documentation (because there are already so many great new
 > features/details), before completing the code, I will have a hard
 > time arguing against this. I also know that if I sit down with a
 > client to do a demo of their nice new website and it takes forever
 > to appear on screen because of this, then we might not be able to
 > spread OPS as fast as we would like.

Yes. We need four hands and 48-hour days ;-)

-Erik




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi Erik

I went back to the XForms Sandbox example on your server and it already
has this
<table id="xforms-messages" style="display: none">
etc

So I looked at BizDoc NG, and it has it too.

Thanks
Colin

On Nov 9, 2005, at 3:09 PM, Erik Bruchez wrote:

> > But if you look at what gets delivered to the browser there is still
> at
> > least one table - I haven't done anything yet to cause it to become
> > visible but it seems to be for error messages.
>
> Again a symptom of XForms Classic ;-)




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

You are right, I see that this is in fact added by theme.xsl, not by the
XForms engine. The good news is that since this is the case, you will be
able to change it easily if it is broken (i.e. with tables). I think we
are still working on how to deal with global alerts, by the way, so this
may not be the final solution.

-Erik

Colin O'Brien wrote:

--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hello Erik

in my original email there were a number of issues I raised that you
said might be indicative of me doing something to switch the server
into XForms Classic mode.
This is the only one that does not fall to another explanation...

On Nov 9, 2005, at 11:21 AM, Colin O'Brien wrote:

> The url that the user arrives at after submitting the form (the
> result) has my pagename but then appended is a great long string
> starting %24instance=

Do you have something like a list of things that trigger Classic mode?
Or any tips on where to start checking.

My test forms example is a customized version of the XForms Sandbox
example
(and indeed, if I run the XForms Sandbox code added to my project, it
does the same thing).
I am running a nightly build from Nov 10.

Thanks & regards
Colin




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Colin O'Brien wrote: The good news is that there is only ONE thing, and it's using an
"xforms" attribute on a <page> element in the page flow.

> My test forms example is a customized version of the XForms Sandbox example
> (and indeed, if I run the XForms Sandbox code added to my project, it
> does the same thing).

Certainly if your example runs in the XForms sandbox, it's using XForms NG.

What does your <xforms:submission> element look like?

-Erik



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Hi Erik,

like I said, I am not running *in* the XForms Sandbox, my form *is* the
XForms Sandbox.
Well, mine is a modified version, but if I copy all the relevant
original files into my project, make any path adjustments, and run it,
I still get the instance etc on the result URL.
Here is the relevant page flow

     <page id="upload" path-info="/xforms-sandbox"
view="sandbox/upload-view.xhtml">
         <action when="/*/action = 'upload' and /*/file != ''"  
action="sandbox/upload-action.xpl">
             <result page="sandbox" transform="oxf:xslt">
                 <xsl:transform version="2.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" >
                     <xsl:template match="/">
                         <xsl:copy-of select="doc('input:action')"/>
                     </xsl:template>
                 </xsl:transform>
             </result>
         </action>
     </page>

     <page id="sandbox" path-info="/xforms-sandbox/sandbox"
view="sandbox/sandbox-view.xpl"/>

I'm obviously missing something, but I don't see an xforms attribute on
the page element.
I've just updated to today's nightly build and my web.xml file is still
uptodate.

Thanks for your help
Colin

On Nov 14, 2005, at 5:42 PM, Erik Bruchez wrote:



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

I think I understand better. Did you by any chance remove the
instance-passing="forward" attribute in the page flow?

The XForms Sandbox example has two pages. The first page passes the
uploaded XML document to the second page by using an internal
submissoin. If you tell the PFC to pass data with a forward, you won't
see the document on the URL. But if you tell the PFC to do a redirect
(the default), the the only choice the PFC has is to pass the XML
submission as a parameter in the URL.

I think this, or something close, explains what you are seeing.

-Erik

Colin O'Brien wrote:


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Ah yes, thanks, I hadn't paid attention to what was in the config  
element in the example.
If I add the attribute to the config on my page-flow, then indeed I no  
longer get the instance etc on the result URL in the browser.

Unfortunately I have now lost something that I was getting.
Instead of the URL (path-info) from my result page, now the browser  
address shows
/xforms-server-submit

Is it really one of the other?

Colin

On Nov 15, 2005, at 5:03 PM, Erik Bruchez wrote:



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Colin O'Brien wrote: For now, yes, unless you want to encode information in the URL path,
which you can do with xforms:load.

But as we discussed with Eric in another thread, we would like to solve
the question of the URL at some point.

-Erik



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws