Ubiquity XForms and eXist db

[Fraser]

Has anyone had any success using Ubiquity with eXist? I haven't been
able to get any of the examples working when I deliver them from an
eXist xquery. Is there something in the serialize content-type or
doctype that needs to be set?

Thanks!

Fraser

[Erik]

Hey Fraser,

Have you had any luck Fraser? I have just recently started an example
application with Ubiquity and eXist. It seems to work great. Let me
know what your specific issue is. I'm assuming it may be a cross site
scripting issue if your using eXist's REST interface.

Let me know,

Erik

[Mark Birbeck]

Hi Erik,

How about an article on how to do this, for the XForms Developer Zone. :)

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.b...@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

[Erik]

Hey Mark,

Yup that is the plan. I will post it when I'm done as for Fraser ping
me if you need any help.

Thanks,

Erik



On Oct 21, 12:53 pm, Mark Birbeck <mark.birb...@webbackplane.com>
wrote:

> Hi Erik,
>
> How about an article on how to do this, for the XForms Developer Zone. :)
>
> Regards,
>
> Mark
>
> --
> Mark Birbeck, webBackplane
>

> mark.birb...@webBackplane.com

>
> http://webBackplane.com/mark-birbeck
>
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)
>

[Fraser]

I have managed to get basic forms generated from xqueries in eXist to
load with Ubiquity although I still have a few issues. Here are the
steps to get it working:

1. Build a copy of the Ubiquity release from svn and load into eXist
as a resource
2. Create an xquery that generates an html document with xforms
elements embeded within it. Remember that the xforms model must go
inside the html body element rather than the head element.
3. Insert the following element at the top of the html head section in
your html output (adjusting for the appropriate path): <script src="/
exist/rest//dbs/some/path/ubiquity-xforms/src/ubiquity-loader.js"
type="text/javascript">/**/</script>
4. At the top of the xquery document, after any namespace declarations
and import statements, insert the following declaration to ensure that
the output is serialized as html: declare option exist:serialize
"method=xhtml media-type=text/html indent=yes";

One of the issues I had is that I have designed my application so far
using the mozilla plugin. In order for the mozilla plugin to work,
the output must be serialized as xml. In order to handle both html
and xml output, I had to have two index pages that call the main
html / xforms xquery: index.xq and index-xml.xq. In the head of the
html output I put the following javascript to redirect if the browser
is firefox and has the xforms plugin installed:

<script language="JavaScript" type="text/JavaScript">
<!--
if(location.pathname.match('index.xq'))
{
if (isFirefox())
{
if (hasMozXForms())
{
var url=location.href;
var redirect=url.replace(/index.xq/,"index-xml.xq")
window.location = redirect;
}
}
}
else if (!hasMozXForms())
{
var url=location.href;
var redirect=url.replace(/index-xml.xq/,"index.xq")
window.location = redirect;
}
function isFirefox() {return (navigator.appName ==
'Netscape' && !navigator.appVersion.match('AppleWebKit')); }
function hasMozXForms() {return
(document.implementation.hasFeature("org.w3c.xforms.dom", "1.0"));}
-->
</script>

This isn't really a great solution but I haven't been able to come up
with anything else. Once Ubiquity is performing as well as the
mozilla plugin I could skip this redirect and have only one index.xq
file.

When loading the more complex xforms required for my application,
unfortunately most of the functionality that is working using the
mozilla plugin is not working using the Ubiquity processor. Here are
some of the issues I have identified:

1. IE seems to have problems completing the load of the ubquiquity
javascript as the "loading...." message stays visible and the form
controls don't render. Even an html login form won't submit.
2. Webkit browsers render the form controls ok but none of the
submissions work. In the process of debugging I once saw a message
able an issue with parsing UTF-8 but I can't seem to replicate that
message at the moment.
3. Webkit browsers break a lot of the css that is working in the
mozilla plugin
4. Webkit browsers don't seem to be able to handle a switch/case
inside of a repeat.
5. While the page is loading, the xforms model shows in the browser.
It creates a disturbing affect when navigating from page to page.

Despite these issues I'm very excited about the progress of the
Ubiquity project and appreciate very much the hard work of the
developers. I agree completely with Mark's advocacy for declarative
web development tools like xforms and progressive browser enhancement
using javascript to bridge between the advent of new declarative
approaches and the native capabilities of browsers. My application
currently only works in Firefox using the plugin so getting it to work
with Ubiquity would be really critical.

I hope this feedback helps the progress of Ubiquity.

Cheers,

Fraser

[Phil Booth]

Hi Fraser,

This is all good stuff, so thanks for the feedback. I'll raise issues
to look into the things that aren't already raised.

Just on your fifth point quickly:

> 5. While the page is loading, the xforms model shows in the browser.
> It creates a disturbing affect when navigating from page to page.

There are a couple of things you could do here.

Firstly, you can build a rolled-up version of the library that removes
all of the dynamic YUI loader stuff. This will significantly improve
the loading speed of your forms. If you want to do this, you just need
to run the build/prepare-distribution.bat script on a Windows box,
then point your forms to build/dist/src/ubiquity-loader.js instead.

Your second option, if that isn't good enough, is a bit hackish, but
you could just to put your model inside a div set to display:none. But
the first option is obviously worth trying before this because of the
general speed improvement that you will benefit from.

Cheers,
Phil.

[Phil Booth]

Hi again Fraser,

I'm having trouble reproducing three of the issues from your email:

> 2. Webkit browsers render the form controls ok but none of the
> submissions work.  In the process of debugging I once saw a message
> able an issue with parsing UTF-8 but I can't seem to replicate that
> message at the moment.
> 3. Webkit browsers break a lot of the css that is working in the
> mozilla plugin
> 4. Webkit browsers don't seem to be able to handle a switch/case
> inside of a repeat.

Have you got a sample form you can send across that demonstrates them?

Cheers,
Phil.

[Fraser]

I appologize for taking so long to come back to you with assistance on
debugging these issues. It's taken me some time to get some other
issues solved. After a fair amount of brute force trial and error
I've identified one issue that affects proper binding of controls to
the xforms model:

Becase the eXist atompub system doesn't return namespace prefexes for
newly created entries, I ended up with entries where elements may or
may not have the atom namespace prefix:
<atom:entry xmlns:atom="http://www.w3.org/2005/Atom">
<id xmlns="http://www.w3.org/2005/Atom">urn:uuid:00002-content</
id>
<atom:title>Home</atom:title>
</atom:entry>

Using the Mozilla xforms plugin, you have to use the atom prefix in
binding statements for both id and title:
<xf:output ref="atom:id"/>
<xf:output ref="atom:title"/>

Using Ubiquity XForms you have to use the literal element name:
<xf:output ref="id"/>
<xf:output ref="atom:title"/>

Regarding submissions, here are some of the issues I've been able to
identify:

1. Get submission
instance:
<cms:LastIDs xmlns:cms="http://www.innoventive.org/cms">
<cms:LastNodeID>203</cms:LastNodeID>
<cms:LastObjectID>210</cms:LastObjectID>
</cms:LastIDs>

Submission:
<xf:submission id="loadLastIDs" replace="instance"
instance="lastIDs" method="get">
<xf:resource value="/exist/rest/db/cms/sites/site1/data/
LastIDs.xml"/>
</xf:submission>

Result:
I have set up actions to output the content of xforms-submit-error and
xforms-submit-done events. When I send the above submission I get the
following submit error results and no submit done results:

Error Messages
error-type: resource-error
resource-uri: http://localhost:8080/exist/rest/db/cms2/sites/site1/data/LastIDs.xml?username=Username&password=Password
response-status-code: 200
response-headers:
response-reason-phrase: OK
response-body:

Submit Done Messages
resource-uri:
response-status-code:
response-headers:
response-reason-phrase:

Despite the status 200 OK, the get request doesn't update the
instance. It is also a bit strange that it added the ?
username=Username&password=Password to the resource uri. This is the
first instance in the model. If I put a ref attribute on the
submission it serializes the bound instance into the uri.

[Fraser]

2. Post Submission
Instance:
<xf:instance id="contentObjectEntryEditInstance">
<atom:entry>
<atom:updated>2009-11-09T18:19:16+01:00</
atom:updated>
<atom:published>2009-11-09T18:18:07+01:00</
atom:published>
<link xmlns="http://www.w3.org/2005/Atom" href="?
id=urn:uuid:e2b1153e-58b6-4432-98e9-284074956ab0" rel="edit"
type="application/atom+xml" />

<atom:id>urn:uuid:e2b1153e-58b6-4432-98e9-284074956ab0</atom:id>
<cms:VersionNumber>8</cms:VersionNumber>
<cms:Language>en</cms:Language>
<cms:Status>published</cms:Status>
<atom:title>Products</atom:title>
<atom:category term="ContentObjectEntry"></
atom:category>
<atom:author>
<atom:name>admin</atom:name>
</atom:author>
<atom:category label="Folder" scheme="contentType"
term="Folder"></atom:category>
<atom:content type="xml">
<cms:Folder>
<cms:ShortName>Products</cms:ShortName>
<cms:LongName></cms:LongName>
<cms:ShortDescription></
cms:ShortDescription>
<cms:LongDescription></
cms:LongDescription>
<cms:ShowChildren></cms:ShowChildren>
</cms:Folder>
</atom:content>
</atom:entry>
</xf:instance>

Submission:
<xf:submission id="createVersionEntryDraft"
replace="instance" ref="instance('contentObjectEntryEditInstance')"
method="post" mediatype="application/atom+xml">
<xf:resource value="concat(instance('resources')/
ContentObjectFeedResource,'/',instance('nodeEntry')/cms:ObjectID)"></
xf:resource>
</xf:submission>

Result:
Error 400 Parsing exception: fatal error at (1,51) : The prefix "atom"
for element "atom:entry" is not bound.

Because the atom namespace and prefix are declared in the html
element, they are stripped by eXist from the instance. Same for the
cms namespace and prefix. When I deleted the namespace declarations
from the html element they were submitted with the entry and the above
error dissappeared. However, I don't think that Ubiquity properly
added to the mediatype application/atom+xml to the submission header
because the entry gets stored as an xml resource and an atom media
relation entry is created pointing to the newly created xml resource.
This is the behaviour of the eXist atom pub service when the mediatype
application/atom+xml is omitted.

So, two issues with the post submission:
1. Ubiquity is not referencing namespace declarations made in
ancestor elements to the submitted element during sibmission
validation checking.
2. Ubiquity is not properly applying the mediatype to the submission
header

[Fraser]

2. Put Submission:

Instance:
<xf:instance id="nodeEntry">
<atom:entry>
<atom:id>urn:uuid:57f71f41-b7ba-4264-
b1ce-1b581bfadff4</atom:id>
<atom:updated>2009-11-10T01:58:09+01:00</
atom:updated>
<atom:published>2009-10-15T20:09:15+02:00</
atom:published>
<atom:link href="?id=urn:uuid:57f71f41-b7ba-4264-
b1ce-1b581bfadff4" rel="edit" type="application/atom+xml"></
atom:link>

<atom:title>Products</atom:title>

<atom:category label="Node Entry"
scheme="nodeEntry" term="/NodeEntry"></atom:category>
<cms:NodeID>110</cms:NodeID>
<cms:ParentNodeID>2</cms:ParentNodeID>
<cms:ObjectID>110</cms:ObjectID>
<cms:SortMethod>name</cms:SortMethod>
<cms:SortOrder>ascending</cms:SortOrder>
<cms:Priority>4</cms:Priority>
<cms:Visibility hidden="false" invisible="false"></
cms:Visibility>

<atom:author>
<atom:name>admin</atom:name>
</atom:author>

</atom:entry>
</xf:instance>

Submission:

<xf:submission id="updateNodeEntry" replace="instance"
ref="instance('nodeEntry')" method="put" mediatype="application/atom

+xml">
<xf:resource value="concat(instance('resources')/

NodeFeedResource, instance('nodeEntry')/atom:link[@rel='edit']/@href)"/
>
</xf:submission>

Result:
Error Messages
error-type: resource-error
resource-uri: http://localhost:8080/exist/atom/edit/cms2/sites/site1/data/nodes?id=urn:uuid:57f71f41-b7ba-4264-b1ce-1b581bfadff4
response-status-code: 400
response-headers
response-reason-phrase
Resource nodes does not exist in collection /cms2/sites/site1/data
response-body
Error 400 Resource nodes does not exist in collection /cms2/sites/
site1/data

I think this issue is related to the fact that the correct mediatype
(application/atom+xml) is not added to the submission header and
therefore eXist is expecting "nodes" to be a resource rather than an
atom feed collection.

[Fraser]

A final, and more minor issue is that the dispatch element is not
working for custom events.

Event:

<xf:action id="editEntryAction" ev:event="editEntryEvent">
<xf:send submission="loadContentObjectFeedforEdit"/>
</xf:action>

Trigger with Dispatch:
<xf:trigger id="editEntryTrigger" appearance="full"
class="floatLeft">
<xf:label>Edit</xf:label>
<xf:action ev:event="DOMActivate">
<xf:dispatch name="editEntryEvent"
target="editEntryAction"/>
</xf:action>
</xf:trigger>

I hope these examples help to resolve the issues.

Cheers,

Fraser

[Phil Booth]

Hi Fraser,

One possibility that springs to mind with the GET submission issue is
a bug that I recently fixed locally, but that has not yet made it into
the trunk. Basically, if @replace="instance" and the server responds
with a content type of text/xml, Ubiquity XForms is erroneously
failing the submission.

As I say, I already have a fix for this so if you have any urgent need
to try it out, let me know and I'll send you a patch. If not, then it
should make it into trunk some time during the next few weeks.

The issues with POST and PUT submissions don't seem familiar to me, so
I'll investigate them separately and raise issues on Google Code in
due course.

Cheers,
Phil.

2009/11/10 Fraser <frase...@gmail.com>:

--
Phil Booth, webBackplane
phil....@webbackplane.com
http://webbackplane.com/phil-booth

[Phil Booth]

Hi Fraser,

This last issue looks like it is actually a mistake in the markup
(unless it is just a copy/paste error I'm seeing). Anyway, XForms
actions actually listen for events on their parent (e.g. model,
submission, a form control...) unless indicated otherwise with the
ev:observer attribute.

So in your code, where you are attempting to target the
'editEntryEvent' at the id 'editEntryAction', this is wrong because
that is the id of the action element itself. Instead, assuming that
your action is inside the model for example, then the target (or
targetid) attribute of your dispatch element should actually be the id
of the model. I've attached an example form that demonstrates what I
mean.

Of course, if it turns out that this was just a copy/paste error in
the email itself, send me the full form and I'll take another look.

Cheers,
Phil.

2009/11/10 Fraser <frase...@gmail.com>:
>

[Fraser]

Hi Phil,

Thanks for the tip on the dispatch element. Mozilla plugin doesn't
support the targetid and uses the older target attribute. I had
forgotten about that. Also the xforms spec isn't very clear on what
the targetid should refer to so thanks for clarifying that for me.
Interestingly the mozilla plugin worked correctly when I targeted the
actual action element in the model. I've now put both target and
targetid attributes on my dispatch elements and set them to the id of
the model containing the action I want to trigger. This works now in
both Mozilla plugin and Ubiquity.

While the mozilla plugin is really great, I'm very keen to get away
from the restrictions of having to serve the page as xml and being
limited to Firefox only. This is why Ubiquity is so exciting! For
example, I've figured out how to integrate CKEditor with xforms but it
only works in an html page due to the javascript .write issue. When
Ubiquity reaches the capability of the xforms plugin I will be very
very happy! So to get using ubiquity as soon as possible I'd be
grateful if you could share your patch for the get problem. I can
then move one step closer and it might help me figure out the other
problems.

Cheers,

Fraser

[Phil Booth]

Hi Fraser,

Okay, I've committed the fix to my changes area in svn, to save you
the hassle of applying the patch manually. If you want to try it out,
you need to check out the following folder from svn:

http://ubiquity-xforms.googlecode.com/svn/changes/phil....@webbackplane.com/issue-608

This gives you a carbon copy of the current trunk, just with the extra
changes that I've made to src/lib/xforms/xforms-submission.js. If you
update your forms to point them at the ubiquity-loader.js in the newly
checked-out area, you'll be able to see whether or not my change fixes
your issue.

Of course, there are no guarantees, so I apologise if it has no effect. :)

Cheers,
Phil.

2009/11/10 Fraser <frase...@gmail.com>:
>

[Fraser]

Hi Phil,

Thanks for sharing your fix. I built a new distribution from your
version and used the rollup. Unfortunately it didn't resolve my
issue. The get request still erroneously picks up the first instance
and serializes it as parameters (e.g. ?x=y) and although it reports
200 OK, it does so in the xforms submission error messages and it
doesn't change the instance. Or, it may change the instance but that
change is not reflected in my output control so perhaps it isn't
triggering an xforms-rebuild event.

So, to summarize potential issues identified:

GET SUBMISSION
Ubiquity is serializing the first instance as parameters, triggering
an xforms-error event and is not properly updating the instance when
replace="instance" is used.

POST SUBMISSION

1. Ubiquity is not referencing namespace declarations made in
ancestor elements to the submitted element during sibmission
validation checking.
2. Ubiquity is not properly applying the mediatype to the submission

header.

PUT SUBMISSION

Ubiquity is not properly applying the mediatype to the submission

header.

I'd be grateful for any other insight or suggestions for how these
issues could be resolved.

Cheers,

Fraser