login required? (trouble getting started)

7 views
Skip to first unread message

cmsmcq

unread,
Aug 23, 2010, 9:44:35 PM8/23/10
to Ubiquity XForms Developers
In trying to get started using Ubiquity XForms, I've encountered a few
problems that may be mentioning here. I mention them here in the
hopes that they will be helpful to the project when the time comes to
smooth off some more rough edges in the release engineering of the
tool.

(1) It took me a while to realize (if that's the right word) that the
reason I was not finding anything in the Downloads tab that looked
like "Download current version of UXF" was that normal usage won't
involve downloading UXF at all, but using it from the Google code
site. At least, that's the impression I get from the wiki article on
Using the Library (http://code.google.com/p/ubiquity-xforms/wiki/
UsingTheLibrary).

(2) I spent more time than felt comfortable looking for some
overview / introductory documentation, or a wiki article called
Installing UXF or Getting Started or something of that kind. I
glanced past "Using the Library" several times because it sounded like
some kind of advanced topic: I don't want to use a library, I
reasoned to myself, I want to install UXF.

If the time has not yet come for simple getting-started guides and
that sort of thing, it might be a worthwhile investment of time to
spend ten minutes on a Getting Started document that says, in effect
"There will be good getting-started instructions here eventually,
aimed at authors of XForms applications. Right now, however, there
aren't any: if you feel comfortable grabbing the SVN repository and
reading the source, have at it! Otherwise, you might want to check
back later for a smoother learning curve."

(3) When I try to use UXF in a simple form, I get unexpected
behavior. This is what I did:

1 Following the instructions in the Using the Library page, I put a
script element in my form document, with src="http://ubiquity-
xforms.googlecode.com/svn/tags/0.7.0/src/ubiquity-loader.js".

2 I opened the document with a browser (tried both Safari and
Firefox).

What I expected: I expected that my simple XForm should display,
perhaps with an error message because it lacks an xf:model element. I
expected that the sample from Using the Library would display normally
(i.e. as a form).

What I got: a modal alert box saying

To view this page, you must log in to this area on
ubiquity.googlecode.com:80:
Google Code Subversion Repository
Your password will be sent unencrypted.

My question: is this expected? That is, in the current state of the
project are forms authors experimenting with UXF expected to acquire a
Google Code signon and use it each time they load the Javascript? If
so, it might be helpful if the Using the Library article mentioned
that. If it's not expected, perhaps something is wrong in my setup,
or elsewhere.

Enlightenment would be welcome.

cmsmcq

unread,
Aug 25, 2010, 12:31:41 AM8/25/10
to Ubiquity XForms Developers
On Aug 23, 7:44 pm, cmsmcq <cms...@blackmesatech.com> wrote:
...
> (3) When I try to use UXF in a simple form, I get unexpected
> behavior.  ...
> What I got:  a modal alert box saying
>
>     To view this page, you must log in to this area on
> ubiquity.googlecode.com:80:
>     Google Code Subversion Repository
>     Your password will be sent unencrypted.

Since writing this, I have had the experience that sometimes the
form seems to work as expected (without prompting me for a
username and password) and other times the behavior described
earlier is experienced. I don't yet have a grip on the pattern, but
will report here when I do.

cmsmcq

unread,
Aug 25, 2010, 10:37:03 PM8/25/10
to Ubiquity XForms Developers
On Aug 24, 10:31 pm, cmsmcq <cms...@blackmesatech.com> wrote:
> On Aug 23, 7:44 pm, cmsmcq <cms...@blackmesatech.com> wrote:
> ...

> Since writing this, I have had the experience that sometimes the
> form seems to work as expected (without prompting me for a
> username and password) and other times the behavior described
> earlier is experienced.  I don't yet have a grip on the pattern, but
> will report here when I do.

During a long few hours today I checked every variation I could
think of: form loaded from local file system vs. form loaded from
server; action URI an absolute URI for a WebDAV directory vs.
a relative URI (pointing, in the case of forms loaded from the Web, at
the same WebDAV directory), different file names, etc. It appears
that when I'm running Firefox (3.0.19, I'm behind the times), forms
whose filename ends .html or .xhtml produce the unexpected behavior
of prompting the user for a userid and password for googlecode.com.
If the filename ends in .xml, I don't get a prompt and everything
works
normally. Using Safari, on the other hand, .xml doesn't work, and
.html and .xhtml both prompt for userid and password, but then
work normally anyway.

If further details would help anyone, I can provide them.

--C. M. Sperberg-McQueen

Mark Birbeck

unread,
Aug 31, 2010, 4:58:35 AM8/31/10
to ubiquit...@googlegroups.com
Hi Michael,

Sorry for the delay in replying, but it seems that quite a few of us
have been on holiday at the same time!

GETTING STARTED

First, many thanks for your input on the problems of 'getting
started'; we're going through a restructuring of the code and
documentation at the moment (more on this below), and your comments
will be invaluable.


LIVE EXAMPLES

Second, on the question of live examples, here are a few:


<http://backplanejs.appspot.com/samples/xforms/xforms-hint.html>
<http://xformsdz.org/article/2009/09/easy-map-controls-ubiquity-xforms>

The first demonstrates the myriad ways that you can display a hint,
including embedding HTML and even XForms inside the hint, whilst the
second shows the custom control architecture in operation, as we bind
Google Maps to output and range controls. (It also shows UXF
coexisting with jQuery in the same page, as well as how UXF can be
used in Drupal.)


UXF STATUS

Finally, to give you a sense of where UXF is at, large-scale changes
are being made to the code, but in a separate repository
(backplanejs). From there they will then be ported back to UXF.

The main reason behind this was simply because my company had some
pressing changes that needed to be made for a customer, and it was
easiest for us to just get on and make those changes in isolation.
However, the issue you raise of how difficult it is for new users to
get started also prompted us to use this 'isolation' as an opportunity
to rethink the build tools, how code is contributed, the test-suite,
deployment scenarios, and so on.

Many of these issues have been addressed, and this code will be
contributed back shortly.

Alongside this reorganisation, we've also been fixing bugs and
speeding up the code, and you'll find the updated library much, much
faster.

I hope that helps, and once again, sorry for the delay in responding.

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)

> --
> You received this message because you are subscribed to the Google Groups "Ubiquity XForms Developers" group.
> To post to this group, send email to ubiquit...@googlegroups.com.
> To unsubscribe from this group, send email to ubiquity-xfor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ubiquity-xforms?hl=en.
>
>

freerick

unread,
Sep 29, 2010, 1:56:58 PM9/29/10
to Ubiquity XForms Developers (Users)
cmsmcq,
I had the same problem. I realized that the file /src/ubiquity-
loader.js is missing from the 0.7.0 tag for some reason and in the
code it is referenced by its location in the SVN repository. I pulled
that file down separately from trunk and placed it in the src
directory and then went ahead and changed the reference to the file
from the location in SVN to the local location in /src where I had
saved it.
The reason we are seeing a username / password dialog box is because
the SVN repository, although accessible from the web, does not allow
anonymous access or at least requires you to explicitly specify a
username. It is quite possible that none of the committers have caught
this error because they are likely all already authenticated with the
SVN server via an existing HTTP session.

I hope this helped.

Best,

Patrick
Reply all
Reply to author
Forward
0 new messages