some precisions about time and access.

Hello,

Could I get some precisions about the synchronisation model for the ops
implementation of xforms hosted by xhtml ?

I think I could get these precisions by myself reading the code and the
document in some places, but some others should have a better synthesis
and precisions.

The overall model is asynchronous (I don't think there are concepts of
synchronisation in xforms ; all are events and responses for events, but
I may be wrong). The Ajax level is asynchronous. I can guess the
complete system is asynchronous.

But some questions keep uncertain. For example, when an xforms:action is
declared for a DOMFocusIn event targeted to and observed by an input
control, what about the synchronisation observed by the user ? All the
actions are executed, and only after that, the user gets the focus, or
the two situations arise in paralel ? If so, if the action is a setfocus
to another input control and the setfocus has a poor responsivness, the
user can do some input on the input control which was intended to be
skipped (according an intuitive semantic, which I don't think it is the
xforms one).

Are there precise answers to this question (level of parallelism between
xforms engine and browser engine for a maximum of the categories of
interaction).

More generaly, I have some questions for the choices about wait or
intermediate states. Is the flag loading pure information, or are there
some real wait states behind ? If it is the case, they could be used
like tools to implement some synchronisation for applications which need
it. A way of doing a good work just beside the norm.

A third question, which is also about navigating.
Do ops implement, and if so, are there some precisions about access keys ?

Gérard Calliet
esad-id




--
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

Gerard,

 > Could I get some precisions about the synchronisation model for the
 > ops implementation of xforms hosted by xhtml ?

Sure!

 > The overall model is asynchronous (I don't think there are concepts
 > of synchronisation in xforms ; all are events and responses for
 > events, but I may be wrong). The Ajax level is asynchronous. I can
 > guess the complete system is asynchronous.
 >
 > But some questions keep uncertain. For example, when an
 > xforms:action is declared for a DOMFocusIn event targeted to and
 > observed by an input control, what about the synchronisation
 > observed by the user ? All the actions are executed, and only after
 > that, the user gets the focus, or the two situations arise in
 > paralel ?

The XForms client (that runs in the web browser) tries to queue events
and group them for sending to the XForm server. "Soon" after you click
in the input control, a message will be sent to the server for
processing. But the client will already set the focus to the input
field you clicked on and allow input in it. This is done so that the
user interface remains as responsive as possible given the potentially
high latency due to the communication with the server.

When the response from the server arrives, we apply the necessary
changes on the client. We have an algorithm that allows us not to
discard conflicting changes made by the user on the client while the
server was doing its processing.

 > If so, if the action is a setfocus to another input control and the
 > setfocus has a poor responsivness, the user can do some input on the
 > input control which was intended to be skipped (according an
 > intuitive semantic, which I don't think it is the xforms one).

I think that's what will happen. Your proposed scenario would be, by
the way, a horrible way of "skipping" focus in an application, so I
don't think it is a big deal. A better way of dealing with this would
be to make the input field read-only in the first place if you don't
want users to be able to click on it.

 > Are there precise answers to this question (level of parallelism
 > between xforms engine and browser engine for a maximum of the
 > categories of interaction).

If by that you mean a place in the documentation where this is
documented, the answer is no. Use the source, Luke ;-)

(But by the way, as far as I know you won't find such detailed
information for HTML and DOM as implemented in today's major browser
either. Our experience is that browsers implement event handling and
dispatching, well, the way they implement it, and sometimes you can't
even count on the events arriving to your handlers in the order they
were dispatched.)

 > More generaly, I have some questions for the choices about wait or
 > intermediate states. Is the flag loading pure information, or are
 > there some real wait states behind ?

That flag just indicates, after a delay, that there is some processing
going on on the server.

 > If it is the case, they could be used like tools to implement some
 > synchronisation for applications which need it. A way of doing a
 > good work just beside the norm.

I don't understand what you mean here. What kind of synchronization
are you trying to achieve, and for what final purpose?

 > A third question, which is also about navigating.
 > Do ops implement, and if so, are there some precisions about access
keys ?

We do copy the XForms accesskey attribute to the corresponding HTML
form elements when possible. I believe that this is all we do at the
moment.

-Erik

--
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/



--
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

Erik Bruchez a écrit :

> Gerard,
>
> > Could I get some precisions about the synchronisation model for the
> > ops implementation of xforms hosted by xhtml ?
>
> Sure!

Thanks for all your answers.

The problem is I don't know where to go until I have the results of the
previous field. So all my other fields would have to be readonly, and
the browsers would tab outside the form. I deal with some legacy
application which knows input / output as interaction with a cell terminal.

The system I have to build must map a synchronous access model (cell
terminal) to an asynchronous model (xforms, brosers, etc...). I think I
would build some adaption layer. And before going into all these
troubles I try to get as much information as I can.

>
> (But by the way, as far as I know you won't find such detailed
> information for HTML and DOM as implemented in today's major browser
> either. Our experience is that browsers implement event handling and
> dispatching, well, the way they implement it, and sometimes you can't
> even count on the events arriving to your handlers in the order they
> were dispatched.)
>
It's just because I knew that I choose a more structured system :-)



p.s. :
"We have an algorithm that allows us not to
discard conflicting changes made by the user on the client while the
server was doing its processing."

Some principles or details, or pieces of code to read ?


Gérard Calliet
esad-id



--
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

 > The problem is I don't know where to go until I have the results of
 > the previous field. So all my other fields would have to be
 > readonly, and the browsers would tab outside the form. I deal with
 > some legacy application which knows input / output as interaction
 > with a cell terminal.

I am not sure of all that entails, but it seems to me that you have a
challenging UI design ahead of you ;-)

 > The system I have to build must map a synchronous access model (cell
 > terminal) to an asynchronous model (xforms, brosers, etc...). I
 > think I would build some adaption layer. And before going into all
 > these troubles I try to get as much information as I can.

That makes sense. A pointer though: consider what's happening between
the JavaScript running browser and the XForms server as private
communication. It's just two parts of the XForms engine. What matters
in the end is how the XForms page interacts with the outside world,
and that will be mainly through XForms submissions.

 > "We have an algorithm that allows us not to discard conflicting
 > changes made by the user on the client while the server was doing
 > its processing."
 >
 > Some principles or details, or pieces of code to read ?

The only pointer I can give you is xforms.js, which contains the
client-side XForms code:

 
http://cvs.forge.objectweb.org/cgi-bin/viewcvs.cgi/ops/orbeon/src/examples/web/ops/javascript/xforms.js

But like most JavaScript code that deals with forms and the DOM, it's
no fun to work with ;-)

-Erik

--
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/




--
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