Testing and using the backplanejs tools
Mark Birbeck
As I've mentioned before I've been refining and factoring the tools
used to build and manage UXF, but I've been doing this over on the
backplanejs project.
Those tools are pretty much ready to be integrated into UXF, so if
anyone has time to help with this, it would be greatly appreciated.
I'd like to do this step-by-step, first checking that I've correctly
listed the prerequisite tools, and that the installation instructions
are clear. Then I'd like to move on to look at how to configure the
tools, before finally doing a build of UXF (and uploading it to Google
Code), creating the documentation (and uploading it to Google App
Engine), and playing with some of the testing options.
So first off, perhaps volunteers could follow the instructions on this page:
<http://code.google.com/p/backplanejs/wiki/InstallingTools>
Are the instructions clear? Any typos, broken links or incorrect
versions? Do the instructions work on all operating systems (or
alternatively, could you say what OS you used, so that we can
cross-reference)?
By the end of the instructions you should have:
* Ant
* Python
* Mercurial
* the backplanejs build tools
* Ruby
* Sprocketize
* Google App Engine
(Note that the only reason you need Mercurial at this stage is to get
the backplanejs tools. Although they will soon be provided as a zip
file, you still might as well get Mercurial now, because we plan to
switch UXF away from SVN in the not too distant future. Also, the only
reason we need Ruby is to support Sprocketize, and we will be moving
away from that too at some point, at which time neither install will
be needed.)
Once we've got a few people past this stage, we'll try the next step.
Thanks in advance, for your help!
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)
Frankie Dintino
Foreign Language Center at the University of Maryland. We are using
ubiquity as the xforms engine for a tool to be used for collecting
texts in foreign languages and developing activities around them.
I've got the xforms test suite running on my dev machine. A few things
I noticed:
A few files were missing from the source. In particular, backplane-
loader.js and xf-behaviors-test-suite.css don't seem to be anywhere in
the repository as far as I can tell. I copied the former from the
ubiquity-xforms repository.
We have been maintaining a fork of the project but would like to merge
in some of our changes. There are a couple of bugs we have addressed
that don't seem to be in the latest revision.
- xf:insert and xf:delete with @at="last()" was giving us issues
since it wasn't evaluating the @at attribute but assuming it was an
integer
- I had numerous problems with nested repeats and itemsets. I
managed to fix these with the following:
- Removing XBL bindings for decorators. This also helped in
dealing with Safari issues since the form was essentially running the
same in WebKit and Gecko.
- Wherever possible avoiding event dispatch through setTimeout().
This had noticeable performance gains on two counts. The first was
that the asynchronous nature of model validation/rebuild/recalculate
resulted in a lot of redundant function calls. In addition, for a form
as large as ours the browser had to keep track of thousands of
functions on the call stack. Wherever it was truly necessary to defer
execution I changed the timeout to 0 seconds. In both Firefox and
Safari if you use setTimeout() with 0 as the second parameter it does
not create a timer but just tacks the function on to the end of the
call stack. The performance gains from doing it this way add up pretty
quickly. On the plus side it makes debugging a lot easier because when
you perform a break the javascript debugger's call stack goes back
farther.
I had trouble getting the third-party/uxf code to work correctly in
the Test Suite. Using our code for ubiquity I get the following
results in both Safari and Firefox.
Elapsed: 05:40 (Safari)
Tests
21 run
7 failed
Commands
171 passed
10 failed
3 incomplete
Failed commands:
TestIterativeInvoke: 6 and 7 (last two before close; both timeout)
TestRepeat: 9 and 10 (two waitForText before the
assetElementNotPresent; both timeout)
TestXFormsRepeat: 9 and 10 (two waitForText before the
assetElementNotPresent; both timeout)
TestReset: 3,4, and 5 failed. The rest do not appear to have been run
TestSelect1: Pretty much all failed, likely some file missing
TestDispatch: command 11 failed (Checks to see if the output's text is
right)
- verifyText
- xpath=/html/body/div[3]/xf:output[@ref="number"]/pe-value
- Actual value '4' did not match '5'
TestMessage: command 36 failed (Checks to see if the message became
visible)
- verifyVisible
- xpath=/html/body/div[7]/xf:input/xf:message
- false
Everything else passed.
Does the Test Suite work for you? If so, does everything pass, or are
the above also failing on your copy as well?
- Frankie Dintino
On Jun 14, 1:31 pm, Mark Birbeck <mark.birb...@webbackplane.com>
wrote:
Mark Birbeck
Welcome to the group!
I'm looking forward to getting your fixes into the code base -- you
certainly sound like you've been busy, and they sound like some
excellent fixes.
If you want to send a patch or two in that we can start looking at and
discussing then please do so on the Contributors list:
<http://groups.google.com/group/ubiquity-xforms-eng>
In terms of the general environment, the way that UXF is currently
hanging together using the YUI loader is very difficult to maintain,
so we're moving to a single roll-up file, which is what the
backplanejs tools do.
In your code are you still using the UXF-style YUI-loader code, or
have you tried the backplanejs tools to create a roll-up file?
Another *major* problem with the current incarnation (and actually
what prompted me to work through restructuring things) is that people
tend to test by using local files, setting all sorts of weird options
in the browser to allow file saving and loading, local use of XBLs and
HTCs, and all sorts of other mystical magic.
In this environment, loading forms from a web-server was regarded as
out of the ordinary!
However, with the new system we say that testing against a web-server
is the 'norm', and anything else is up the developer, based on their
requirements. (We don't want to rule out applications that load files
from a hard-drive, we're just saying that they are out of the
ordinary.)
The consequence is that library developers are testing in the same
environment as form authors who are using the library -- with no weird
configuration settings.
This does mean that you need to have a local web-server, but that is
not exactly unusual; developers are free to choose their own
configuration (Apache, IIS, etc.), but also the backplanejs tools have
settings for Google App Engine.
Anyway, the upshot is that we need to start migrating to that test
environment, so it would help greatly if we could work through that.
So, first step...I can't quite tell if you're saying that you've tried
using the build tools, or whether you're using the tools in UXF?
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.
>
>
Frankie Dintino
Sorry for not being clear on that. On our production server we build the roll-up file using the ubiquity build tools (build-ux.bat). For the test suite that I ran, as described in my post, I generated it through Apache Ant and the new backplane build tools. I have to say I'm glad you're moving in a different direction there; I develop on a mac and have had to open cmd.exe in parallels every time I made an update to ubiquity. This way it's much easier to plug it into the cross-platform build process of the rest of our application.
- Frankie
Mark Birbeck
No...I think you were clear! I just wanted to be doubly sure. :)
I'm a Mac user too, and just about everything I've been doing of late
has been about removing the platform-dependent aspects of UXF. The key
to that is of course using Ant to specify everything.
I've also started to use Eclipse, which can control Ant builds from
within the environment, which I think is very powerful.
And in the past we've used Buildbot, which used Ant builds to give us
continuous integration. This is currently broken, but as we migrate to
the new tools we should easily be able to get it working again.
Best regards,
Mark
John Boyer
Hi Frankie,
Would you mind showing the contributor license agreement to your manager, and getting his permission to fill it out and return it?
If you email a PDF scan of it to me, I can file it in the project repository, at which point we can consume fixes you make into the project.
Thank you,
John M. Boyer, Ph.D.
IBM Distinguished Engineer, Interactive Web Applications and Documents
IBM Lotus Forms Architect
Workplace, Portal and Collaboration Software
IBM Canada Software Lab, Victoria
E-Mail: boy...@ca.ibm.com
Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
| From: | Frankie Dintino <fdin...@gmail.com> |
| To: | ubiquit...@googlegroups.com |
| Date: | 06/15/2010 10:34 AM |
| Subject: | Re: [ubiquity-xforms] Re: Testing and using the backplanejs tools |
Frankie Dintino
Senior Programmer
National Foreign Language Center at the University of Maryland
John Boyer
Hi Mark (and all),
Because I'd like to be able to do all of this in eclipse, I thought I'd take that route while also trying to get as far through the install directions as possible.
For example, eclipse comes with ant, and I can run ant scripts from eclipse, but it still seemed worthwhile to make sure I could call ant -version from the command-line, just in case.
I'm using Eclipse 3.5.1 on Windows XP.
To get ant -version, I just add the following to my environment (pseudo-code):
ANT_HOME = %ECLIPSE_PLUGINS%\org.apache.ant_1.7.1.v20090120-1145
PATH += %ANT_HOME%\bin;
At this point, ant -version works and (obviously) indicates version 1.7.1. I mention it because your instructions calle for 1.8.0 RC1. I'd prefer not to base the production environment off of a release candidate, but I have to believe you're not really relying on RC features. That being said, seems worth asking. If you do need a version other than 1.7.1, it means that eclipse users will be out of luck though.
A similar thing happens with Mercurial. If I go into eclipse software updates, the update site for Mercurial is:
http://cbes.javaforge.com/update
If one picks the top-level checkbox for MercurialEclipse, then it installes the latest and greatest v1.6 plugin but it also (on windows at least) installs windows binaries that have a version of 1.4.3. Not clear at this time why there is a version number different there, but it looked like both were required to get Mercurial to run on windows eclipse anyway. I had an old eclipse 3.4 that I started with, and in that version I had installed the MercurialEclipse plugin but not the windows executables, and Mercurial did not show up as a valid source from which a "New Project" could be created. When I tried to add the windows executables, the update site reported that my (eclipse 3.4) environment did not meet the minimum requirements. So, I didn't try installing only the plugin and not the win32 exe in eclipse 3.5.1, but it's a bit immaterial because the windows executable component is the one that provides hg.exe.
Hence, once I installed MercurialEclipse with the top-level checkbox checked, I could see Mercurial as a valid source for a "New Project".
I also did the following to my environment to get "hg --version" to work:
MERCURIAL_HOME = %ECLIPSE_PLUGINS%\com.intland.hgbinary.win32_1.4.3.v201005111545\os\win32
PATH += %MERCURIALHOME%;
It should be noted at this point that I have downloaded but not installed Python (because the windows executable component lays down a local python dll).
Next up, I did seem to be able to clone backplanejs. I was a little surprised that it let me use the https URL considering I am not a member. Does Mercurial check for group membership on push?
I did also get some errors at the end of the cloning process:
Errors occurred during the build.
Errors running builder 'Integrated External Tool Builder' on project 'backplanejs'.
The builder launch configuration could not be found.
The builder launch configuration could not be found.
Errors running builder 'Integrated External Tool Builder' on project 'backplanejs'.
The builder launch configuration could not be found.
The builder launch configuration could not be found.
Granted I haven't installed python, ruby, sprocketize or the google app engine, and these seem to be ignorable (e.g. perhaps the java perspective being boneheaded), but it seemed worth asking if you think these errors might indicate a larger problem?
Anyway, I'm going to do Python (current 2.x version is now 2.6.5, btw), ruby, sprocketize and GAE next. I wasn't totally clear what you were saying about the first time run of GAE. Are you saying that the first time run will install ant if "it" (what?) doesn't happen? And *as a result* we need to run the dev_appserver.py to prevent another ant from being installed?
Thanks,
John
| From: | Mark Birbeck <mark.b...@webbackplane.com> |
| To: | ubiquit...@googlegroups.com |
| Date: | 06/14/2010 10:37 AM |
| Subject: | [ubiquity-xforms] Testing and using the backplanejs tools |
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
John Boyer
Hi Mark (and all),
As follow-up to my earlier email below, there were no problems installing python (2.6.5) and ruby (1.8.7) on windows using your instructions.
Trivial point is that you have to set python on your path manually to do the version verify.
Ruby's installer gives you the option at least :-)
Almost as trivial, you can't make the leap to installing sprocketize because the ruby install doesn't include gem.
The command to get sprockets ran no trouble. Would you mind explaining the "--remote" in the command line (by comparison, the install for rails does not have it)?
I'll deal with the Google App Engine next time I get a bit of time. Looks like their is an eclipse plugin for that too.
Cheers,
John
Frankie Dintino
Sorry for not being clear on that. On our production server we build the roll-up file using the ubiquity build tools (build-ux.bat). For the test suite that I ran, as described in my post, I generated it through Apache Ant and the new backplane build tools. I have to say I'm glad you're moving in a different direction there; I develop on a mac and have had to open cmd.exe in parallels every time I made an update to ubiquity. This way it's much easier to plug it into the cross-platform build process of the rest of our application.