To Do Lists example featured on ajaxian.com

It's good to see that Orbeon PresentationServer and XForms get some
coverage in the Ajax world :-)

   http://www.ajaxian.com/archives/2005/11/ajaxian_to_do_l.html

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

Le jeudi 03 novembre 2005 à 22:25 +0100, Erik Bruchez a écrit :
> It's good to see that Orbeon PresentationServer and XForms get some
> coverage in the Ajax world :-)
>
>    http://www.ajaxian.com/archives/2005/11/ajaxian_to_do_l.html

Yes, that's nice, congratulations for this coverage!

>From what I have read (and not tried yet, unfortunately) of the support
of XML HTTP POST in OPS 3.0, I have a feeling that OPS could become a
platform of choice for developing Ajax applications (with or without
XForms).

What would be real nice (but would probably be time consuming for you)
is to document the Ajax libraries and practices used by your XForms
implementation so that if people want to extend what is allowed by
XForms or even write non XForms Ajax applications (let's imagine that
someone would like to reimplement Google Maps on top of OPS) they can do
it in a way that is coherent with what you've done (ie use the same
Javascript libraries, the same "style" of client server interaction and
minimize the risks of collusion with the XForms implementation).

Do you think you could cover that (even briefly) in your documentation
or in your blog?

Thanks,

Eric
--
Curious about Relax NG? Read my book online.
                                   http://books.xmlschemata.org/relaxng/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------




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

Eric van der Vlist wrote:

 > Yes, that's nice, congratulations for this coverage!
 >
 > From what I have read (and not tried yet, unfortunately) of the
 > support of XML HTTP POST in OPS 3.0, I have a feeling that OPS could
 > become a platform of choice for developing Ajax applications (with
 > or without XForms).

Absolutely true, at least for the "with XForms" part ;-)

 > What would be real nice (but would probably be time consuming for
 > you) is to document the Ajax libraries and practices used by your
 > XForms implementation so that if people want to extend what is
 > allowed by XForms or even write non XForms Ajax applications (let's
 > imagine that someone would like to reimplement Google Maps on top of
 > OPS) they can do it in a way that is coherent with what you've done
 > (ie use the same Javascript libraries, the same "style" of client
 > server interaction and minimize the risks of collusion with the
 > XForms implementation).
 >
 > Do you think you could cover that (even briefly) in your
 > documentation or in your blog?

First, I think the idea is quite good. We would like to see OPS
integrating more and more "cool" third-party and custom client-side
components, for example, and make it easy, or at least possible, for
developers to add their own. We can also clearly see how such
components would get extra mileage by being plugged into the XForms
philosophy (data binding to XForm instances, in particular).

There are two types of "Ajax" components:

o Pure Javascript components, which read and write their data to and
   from HTML form fields or Javascript variables. Technically, those
   are not really Ajax-enabled, but more and more of those fit into the
   Ajax philosophy.

o True Ajax components, which do require communication with the
   server.

With the OPS XForms engine, such components are currently hooked up in
an ad-hoc way. They include the Calendar widget, which relies on date
formatting done server-side; XForms selection widgets using dynamic
itemsets; the XForms slider control; etc.

One difficulty for generalizing and documenting this is that there is
no winning Ajax framework yet. We are using Sarissa for some support,
but things are changing fast, and we may want to switch or leverage
something else at some point, like Dojo.

By the way, we started listing a series of controls that could be
candidates on our wiki (this may be a little out of date now):

   https://wiki.objectweb.org/ops/Wiki.jsp?page=ControlsImprovements

Feel free to contribute there.

The bottom line is that this is something we need to keep in mind, but
we may have to wait a little bit until we can actually deliver on
it. In the meanwhile, suggestions and discussions are welcome.

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

Le lundi 07 novembre 2005 à 14:05 +0100, Erik Bruchez a écrit :

.../...

> One difficulty for generalizing and documenting this is that there is
> no winning Ajax framework yet. We are using Sarissa for some support,
> but things are changing fast, and we may want to switch or leverage
> something else at some point, like Dojo.

That means that I had to write one these apps, I'd rather use Sarissa
and be warned that I could have to migrate to stay coherent with your
choices!

Are you using "raw Sarissa" or have you developed higher level functions
that we could leverage on (to minimize a possible migration)?
OK, thanks.

Eric

--
Did you know it? Python has now a Relax NG (partial) implementation.
                                          http://advogato.org/proj/xvif/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------




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

On 11/7/05, Eric van der Vlist <[hidden email]> wrote:
> Are you using "raw Sarissa" or have you developed higher level functions
> that we could leverage on (to minimize a possible migration)?

Hi Eric,

We are just using an unmodified Sarissa. We are writing our
client-side code to make it as so that it can coexist with your our
own JavaScript code, if you want to use JavaScript in your pages. For
instance the names of all our top-level functions or object (i.e. in
window or document) start with "xforms", and we always register our
event handlers with addEventListener (Firefox) or attachEvent (IE),
instead of doing obj.onfocus = function() {...}.

But of course, if you notice any issue, please let us know.

Alex



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

Le mardi 08 novembre 2005 à 17:21 -0800, Alessandro Vernet a écrit : Thanks for these guidelines!

Just thinking|dreaming aloud, that would be nice to be able to
declaratively subscribe new widgets, maybe as appearances of existing
XForms controls in user defined namespaces.

That's probably an interesting challenge to implement in XSLT, though.

Speaking of appearances and XSLT, I have noticed that you're struggling
with QNames :

           <xsl:when test="@appearance
                            and namespace-uri-for-prefix(substring-before(@appearance, ':'), .) = $xxforms-uri
                            and local-name-from-QName(xs:QName(@appearance)) = 'image'">
               <!-- TODO: use prefix-from-QName() instead of substring-before() when Saxon is upgraded -->

One thing that could be done would be to create an empty element with
this QName in a variable and apply the templates on this element, or
maybe not just an empty element but an element containing a copy of the
XForms control so that the applied template can easily get the context.

                   <xforms:trigger appearance="xxforms:button">
                        <xforms:label>Go!</xforms:label>
                        <xforms:load ref="/form/uri" ev:event="DOMActivate"/>
                    </xforms:trigger>

would thus be "converted" into :

                 <xxforms:button>
                   <xforms:trigger appearance="xxforms:button">
                        <xforms:label>Go!</xforms:label>
                        <xforms:load ref="/form/uri" ev:event="DOMActivate"/>
                    </xforms:trigger>
                </xxforms:button>

And you'd call xsl:apply-templates on this element.

People could then "register" their widgets by adding their own templates
through xsl:include or xsl:import.

The template for the above element could match either "xxforms:button"
or xxforms:button[xforms:trigger] if it wants to be more specific.

Just an idea...

Eric
Le premier annuaire des apiculteurs 100% XML!
                                                http://apiculteurs.info/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------




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

Eric van der Vlist wrote: Thanks for the suggestion. Note that xforms-to-ajax-xhtml.xsl is the
major bottleneck of XForms initialization performance, and will likely
be replaced by a native solution soon.

-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

Le mercredi 09 novembre 2005 à 13:57 +0100, Erik Bruchez a écrit :

> Thanks for the suggestion. Note that xforms-to-ajax-xhtml.xsl is the
> major bottleneck of XForms initialization performance, and will likely
> be replaced by a native solution soon.

Then, that would be nice if this native solution left some room for
adding custom widgets :-) ...

Thanks,

Eric

> -Erik
>
> pièce jointe document plein texte (message-footer.txt)
> --
> 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
--
Lisez-moi sur XMLfr.
                       http://xmlfr.org/index/person/eric+van+der+vlist/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------




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

Eric van der Vlist wrote: Absolutely, although we have yet to think about how plugging-in new
widgets will be done from end to end.

Unless Saxon's performance does an x10 soon, xforms-to-ajax-xhtml.xsl
won't remain a viable option, at least in its current form. Fixing the
performance issues assocated with this part of the XForms engine is
currently a "P1" issue for us.

-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