Advice on times

[wrussell]

Hi,

The little application I'm working on as part of my evaluation of SmartClient is a scheduling/calendaring thing. I want to be able to work with times of the day without tying the times to a particular date (so you can set up schedules for Tuesdays, or the last day of every month, or whatever).

I had started using java.sql.Time's on the server side, but of course these come back to the Javascript as full date/times on Jan 1st 1970 (and to make matters worse the time is actually wrong because the daylight-saving element has been clobbered due to Jan 1st being in the middle of winter!)

What would you recommend for implementing pure time data in a SmartClient app? Plain integers? Floats? I'd appreciate the advice of anyone who has already done this kind of thing.

[Isomorphic]

Hi Wrussel,
SmartClient actually anticiptes times to be stored as Javascript date objects.

Fields specified as type Time in a dataSource will format JS Date objects as time strings, and will show TimeItem type editors by default.

Take a look at the documentation on the Time class, TimeItem editors, and the available set of timeFormatters for more on this.

Let us know if you run into problems

Thanks
Isomorphic Software.

[wrussell]

Thanks, that's helpful.

However... I am returning a Javabean to SmartClient via DMI RPC (no data sources at the moment, because the UI I want to implement is very specific and doesn't lend itself very well to your provided data-aware widgets), and I'm not sure how I can tell SmartClient that a particular member of the returned object should be treated as a Time rather than a Date. In fact, I'm a bit vague on the whole business of using complex Java objects in SmartClient generally (there's a lot of documentation about data sources, but much less about manually handling objects received via RPC).

With DMI, is there some way of defining a client-side object that the server-side object will map to (so, in this case, I could tell it that the member "start" is a SmartClient Time), or am I barking up the wrong tree?

[Isomorphic]

Hi Wrussel,
We'll respond to your new question shortly.

First, an update on our previous response:

In SmartClient 5.6 all "times" (time type fields in DataSources) are stored as dates, with the time set to the appropriate value in the browsers local time zone. This means that the value displayed to the user may differ depending on the browser's time-zone.

We have decided to change this behavior - as of 5.7 build, times will be still be stored as date objects, but the timezone of the times will be consistent regardless of the browser's local timezone settings. [UTC by default, but this will be configurable].

We have added a patch to the Addendums forum which will allow you to patch the 5.6 Eval build to implement this new behavior. Having applied the patch, Times can be stored as date type objects on the server, ensuring the time value for the date is correct for UTC.

Thanks
Isomorphic Software

[Isomorphic]

Ok - on your other question:

It seems you should be using DataSources to achieve this.

Using DataSources allows you to specify field type - so data returned from the server will be converted into the appropriate type on the client.
Note, this property can be set to a large number of recognized fieldType values, including the ID of another DataSource, allowing for nested complex types.
For raw conversion from XML to JS, you can use the XMLTools.toJS() method, but this does not support the complex data type handling possible with DataSources.


We understand that your UI may not lend itself to using standard databound components, however you can use a DataSource to retrieve data from the server without actually creating a standard databount ListGrid / DynamicForm / etc.
For example if you call dataSource.fetchData(...), you will be able to access the data returned by the server as a simple array of records in your callback function, and apply them directly to your custom UI.

Hope this helps

Isomorphic Software

[wrussell]

Yes, this helps a lot, thanks very much.

Umm, I hate to be dumb, but how do I apply the patch you mention? And if this is a standard procedure, can I suggest that a sticky note on the Addendums forum would be a good idea?

Thanks

[Isomorphic]

Hi
Yes this is a good suggestion - we'll add a sticky message on how to apply patches.

The patch is just a piece of Javascript code to apply to your application.
You should apply it after loading the SmartClient libraries, before any logic for your own application.
The recommended way to do this is to copy and paste the script into a new file, save it on your system as a Javascript file (UTCPatch.js or simillar) and use a normal <SCRIPT SRC=..> tag to include it in your application.

When you upgrade to future SmartClient builds, the patch will no longer be necessary. At this point you can remove both the file and the tag to load it.

Thanks

Isomorphic Software

[wrussell]

I applied this patch as suggested, by pasting the code into a "patches.js" file and including that in my JSP, after the SmartClient includes but before my own code. It doesn't appear to have made a difference: I have an SQL TIME field, populated with a value of 11:45:00. This is read from the database into a java.sql.Time variable, which is sent back to the client as a member of a Javabean.

If I then issue a isc.say(rpcResponse.data.myTimeField), it displays "Thu Jan 01 1970 10:45:00 GMT+0000 (GMT Standard Time)", which is what it displays without the patch. I am in the UK and we are in British Summer Time at the moment, which is GMT+0100 - which I guess accounts for the time being one hour earlier.

Have I misunderstood the intention of the patch? I just want the times stored in my database to be displayed unchanged in my client app...

[Isomorphic]

Hi wrussel,

The intent of the patch is that the time formatters built into SmartClient will always show times in UTC regardless of the user's local time zone. Calling Date.toString() (effectively what you do by way of isc.say()) will still show local time zone.