[OPEN-ILS-DEV] Dojo Release 1.2.0

[Dan Scott]

Ugh. So the showstopper for me has been that the Conify hours of
operation interface seems to change - it now emits the literal value
of the contents of the "open" or "closed" text field ('9:00 a.m.')
rather than the format expected by PostgreSQL ('9:00:00') (you can see
this in osrfsys.log and postgresql log with stmt logging turned on).
In addition, when I select a different time using the mouse in FF3 the
different time doesn't replace the existing time; whereas if I use the
cursor keys + hit enter the new time does get entered.

For at least making input "stick", simple examples like
http://download.dojotoolkit.org/current-dev/dojo-release-1.2.0/dijit/tests/form/test_TimeTextBox.html
seem to work perfectly, but they're not calling methods on an
instantiated aouhoo object. I'm wondering if there's deeper
dojoConnect magic needed in 1.2.0. Or maybe the data passed to the
data store needs to be formatted differently when it gets persisted to
the database vs. how it gets set in the Dojo widget?

I've tried a few avenues at fixing this in org_unit.html:

  * switching the <span> element for the widget to an <input
type="text"> element (matching the 1.2.0 tests)
  * using .getValue() rather than .getDisplayedValue() (thinking that
I want the underlying data, not the literally displayed text)
  * using .attr('value') rather than .getValue() which is now deprecated
  * wrapping various dojo.date.format. and dojo.date.stamp calls
around the retrieved value to format it

I've been able to get it to return Null but haven't had much success otherwise.

Another wild guess is that the deprecation warning from the 1.1 days
about Trees needing to use models rather than data stores in 2.0 might
have ramped up in severity; the deprecation warning is still there in
1.2.0 so data stores theoretically should still work. This is beyond
my ken. I'm floundering, so I'm going to walk away from this problem
for a bit and focus on a round-tripping script for Dojo resources <->
POT for translation purposes. Note that the existing interface works
perfectly with all of the translation changes applied when using Dojo
1.1.1.

I have a few other "upgrade to 1.2.0" notes from earlier, below.

2008/10/5 Bill Erickson <erickson at esilibrary.com>:
> Agreed on 1.2.  However, I put 1.2 on dev.gapines.org and applied the patch
> locally and found 2 additional issues.  We seemed to have lost some styling
> in Vandelay (the blue gradient css) and we're getting the extra scroll bars
> in the Vandelay queue grid (a la pre-LayoutContainer).  LayoutContainers are
> technically deprecated in 1.2, so even though they exist, they may be
> broken.

Good eyes.

> I'm experimenting with alternatives.  If I run into any showstoppers, I'll
> report.

I tried swapping in a BorderContainer for LayoutContainer in
vandelay.xml, and it seems that the problem there is that you're
allowed a maximum of one div per region (LayoutContainer technically
only allowed one "client" per layout, but you seemed to be able to get
away with it nonetheless).

I think Dojo is unhappy that there are multiple region="center" divs
in vandelay.xml, even though their style might be set to display:
none. In the worst-case scenario, how horrible would it be to take the
next step (now that you've split vandelay.xml into multiple included
files) of treating each included file as a separate standalone file?

-- 
Dan Scott
Laurentian University