Opened 11 years ago

Closed 11 years ago

#5363 closed enhancement (fixed)

Changes to timeTextBox and dateTextBox (add un-serialize)

Reported by: guest Owned by: Douglas Hays
Priority: high Milestone: 1.1
Component: Doc parser Version: 0.9
Keywords: timetextbox datetextbox Cc:
Blocked By: Blocking:

Description

In implementing the 1.0 version of dojo/dijit timeTextBox and dateTextBox, I am forced to do one of three things:

  1. Do all server communication in dojo format (yyyy-mm-ddd)
  1. Pre-fill from the server with dojo format, and send to the server in what ever format I choose to serialize into
  1. Alter the value/defaultValue DOM components of the form field before dojo parses (the method I chose, as it was transparent)

Each option has it's problem:

  1. This is going to inhibit the uptake of dojo. If I build with dojo from the start, this would not be such a problem, however if I want to add dojo/dijit to an existing system there is a need logic changes to conform to the dojo way. It is also a format that is native to only a few countries, and a less than optimal user experience for the rest.
  1. Splitting the formats is far from optimal, as I still have to make code changes to roll dojo into an existing system (fewer changes but changes all the same). However in the event that dojo fails, it means that in an edit loop (prefill, alter, submit) that I would have to modify the date on every round trip, causing frustration or form abandonment.
  1. Altering the value/defaultValue is ugly (you need to alter both for dojo/dijit to work in FF and IE 7). Not as it forces you to move parse off into an onload method that only executes after you have looped over all your date instances and updated the value.

A means to "un-serialize" would be ideal, to ease other's implementations!

Attachments (1)

DateTextBox.js (1.1 KB) - added by mrblakwell 11 years ago.
i was in the same boat, doughays and dmachi helped me to come up with this solution

Download all attachments as: .zip

Change History (10)

comment:1 Changed 11 years ago by Adam Peller

With the dijit design and the new dojo.parser, the handling of attribute types like Date is left to the parser. It was deemed to be a cleaner design and gave the toolkit more consistency. We also chose to reduce options, so the lack of choice was by design. I'm not sure exactly what the implications are if we were to allow customization at the parser level, but I know it's complexity we hoped to avoid.

Here's the case for (1): The format chosen was not intended to be native to any country, but rather something neutral. We chose a subset of the ISO format, as did the JSON spec, so at least we're in alignment there. Yes, it's going to mean an extra step for a lot of people, but it forces people to address the i18n aspect and not assume any particular culture. Well designed systems should use a locale-neutral date format for client-server communication.

I can appreciate that a client-side switch or shim is more convenient than a server-side one. (3) sounds like it could bottleneck page loading performance. There are other issues we seem to have to deal with, like SQL, which uses a very similar format but apparently uses a space to delimit date and time instead of "T".

Let's see what bill or alex have to say.

comment:2 Changed 11 years ago by bill

I think you explained our reasons perfectly; I can't add anything to it. FWIW, I'm sure you (the bug reporter) could extend DateTextBox? or TimeTextBox? to use whatever format you like, and you could even embed that code in the HTML page using dijit.Declaration.

comment:3 Changed 11 years ago by guest

Peller, I agree with you on 1, it is the way things should be but unfortunately it isn't how they turn out in many cases (people who write checks tend to have some funny ideas about how things should be). And I also agree with you on 3, it is going to be a problem!

I would love to be able to... "extend DateTextBox? or TimeTextBox? to use whatever format you like" exactly as bill suggests! If there already is a way to do this updating the manual would work great! Right now the doc's around this are a bit thin, suggesting I use XHR callback as a way to perform the above operation, but not illuminating as to how I would go about that in a non XHR implementation.

comment:4 Changed 11 years ago by bill

Owner: set to Douglas Hays
Version: 0.9

Doug, can you handle this one? Looks like we need a code update since MappedTextBox? and TimeTextBox? have a serialize method but no corresponding deserialize (on unserialize?) method. Currently, TimeTextBox?.postMixInProperties() is calling dojo.date.stamp.fromISOString() directly, so there's no easy way to override.

comment:5 Changed 11 years ago by Adam Peller

though this is only for constraints (min/max), so it might be misleading to provide an unserialize method when it isn't effective for all attributes. unserialize would not be symmetrical with serialize, since the parser controls non-compound attributes without extra effort to customize.

comment:6 Changed 11 years ago by bill

Oops, I forgot that the parser does the conversion, so ignore my last comment. It's unclear to me whether the bug author is upset about the format of the value submitted when you submit the form (which you can override by defining serialize for the widget, like <input dojotype=dijit.form.DateTextBox serialize=myFuncToWriteDateToAString>), or is also upset about the format you need to specify for the value of the widget on page download, as in <input dojotype=dijit.form.DateTextBox value="2007-1-1"> . Which is it?

comment:7 Changed 11 years ago by Adam Peller

it's the latter. If we provided an example in the book or in the tests of how to create a custom value attribute which used a special date format, I think we'd be covered. Perhaps we could expand on the OracleDateTextBox? example in the book?

Changed 11 years ago by mrblakwell

Attachment: DateTextBox.js added

i was in the same boat, doughays and dmachi helped me to come up with this solution

comment:8 Changed 11 years ago by guest

Original poster here...

Expand the manual with a recommended work around. For those of us retrofitting dojo onto legacy systems it would be of great benefit ---

comment:9 Changed 11 years ago by Douglas Hays

Component: DijitDocumentation
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.