Closed Bug 331585 Opened 19 years ago Closed 9 years ago

Output that shows date/dateTime in current locale

Categories

(Core Graveyard :: XForms, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: allan, Unassigned)

References

()

Details

Attachments

(2 files, 1 obsolete file)

How about including an output with appearance="?" that "prettyprints" a date/time/dateTime in the current locale, like "February 2nd 2005"?
Assignee: aaronr → xforms
I'd like to see such widget. Just probably we should provide to control date output format, for example, by new attribute introducing (or @appearance using?).
Assignee: xforms → surkov.alexander
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'd like specify date/dateTime format 1) directly (for example, by string like dd.MM.yyyy) 2) by locale Also I'd like to have this feature not only for xforms:output (also, for example, for xforms:input). Can we rise the question on w3c?
(In reply to comment #2) > I'd like specify date/dateTime format > 1) directly (for example, by string like dd.MM.yyyy) > 2) by locale > > Also I'd like to have this feature not only for xforms:output (also, for > example, for xforms:input). Can we rise the question on w3c? > Specific use cases and examples along with a proposed solution will get the best response out of the W3C. You want it to be an attribute on input/output? Wouldn't it be better to propose an xforms xpath function that does the formatting? Similar to http://www.w3.org/TR/xforms11/#fn-local-date
My opinion is that you don't need any XFoms rec changes to do this. In fact, I believe it's already required: http://www.w3.org/TR/xforms/index-all.html#ui-output "Implementation Requirements: Must allow display of a lexical value for the bound datatype. Implementations should provide a convenient means for display of datatypes and take into account localization and internationalization issues such as representation of numbers." Also, you're free to define appearance minimal/compact/full as you want. For dates there are some common interpretations (cf. http://java.sun.com/j2se/1.5.0/docs/api/java/text/DateFormat.html#LONG http://java.sun.com/j2se/1.5.0/docs/api/java/text/DateFormat.html#MEDIUM http://java.sun.com/j2se/1.5.0/docs/api/java/text/DateFormat.html#SHORT)
(In reply to comment #4) > My opinion is that you don't need any XFoms rec changes to do this. > In fact, I believe it's already required: > > http://www.w3.org/TR/xforms/index-all.html#ui-output > > "Implementation Requirements: Must allow display of a lexical value for the > bound datatype. Implementations should provide a convenient means for display > of datatypes and take into account localization and internationalization issues > such as representation of numbers." > So if xf:output is 'required' to show a localized and internationalized representation of the date value in the bound node, then how would the form author go about showing the EXACT value of the bound node? I would assume both capabilities should be 'required' but there can only be one default. I'll assume the EXACT value of the bound node is the default value. We could handle three of the types of display mentioned in the spec Leigh pointed us to by using default to be the exact value of the bound node and using the three @appearance to be three of the possible displays that Leigh noted. But then we are giving up any chance of using @appearance to determine the type of widget. It WOULD be nice if there were some way to format values via the spec, like XSLT's format-number(), especially for formatting values into a monetary format, for example.
Mark Birbeck pointed out that output/@value won't have (at least in XForms 1.0) access to type MIP, so it should always output the lexical value; and output/@ref should use the type MIP as advice to convert the lexical representation into the presentation value, which includes L10N.
I'm fine with xforms output shows exact value and I like idea if output will be able to show exact value. Though other xforms controls don't do it. Date formatting xforms xpath function is be fine but here it's not very usable i.e. they are fitted good for xforms:output if I use @value attribute but I should have some tricks for xforms:input to use it.
The Last Call for XForms 1.1 includes a new, non-normative example for output which clarifies existing text in both XForms 1.0 and XForms 1.1. Since it is just the addition of a non-normative example that follows the existing normative requirements, I believe it applies to XForms 1.0 as well. XForms 1.0 http://www.w3.org/TR/xforms/index-all.html#ui-output says Implementation Requirements: Must allow display of a lexical value for the bound datatype. Implementations should provide a convenient means for display of datatypes and take into account localization and internationalization issues such as representation of numbers. XForms 1.1 last call http://www.w3.org/TR/2007/WD-xforms11-20070222/#ui-output has the same Implementations Requirements, but clarifies them with example: Example: Output of node bound to xsd:date <bind nodeset="birthdate" type="xsd:date" /> ... <output ref="birthdate"> <label>Lexical: </label> </output> <output ref="birthdate" appearance="full"> <label>Full: </label> </output> <output ref="birthdate" appearance="minimal"> <label>Minimal: </label> </output> A graphical browser may take into account the appearance and the localization information from the host language and present the above output form controls as follows: Lexical: 1998-01-19 Full: 19 janvier 1998 Minimal: 19/01/1998 In particular, for dates, I propose that Mozilla XForms do this required localization. Since the Implementation Requirements also list a way to present the lexical value, I propose that output with no appearance attribute continue to present the lexical value of the bound node. Then for appearance='minimal', appearance='compact', and appearance='full', I propose that it present a localized date, time or dateTime. Mozilla XForms already uses appearance='full' to show a mostly static calendar chooser for xsd:date. (It has a bug: it allows you to change the month, even though it's an output.) If this appearance is kept, I would suggest that compact and minimal should do plain text. I have attached a version of the example from the XForms 1.1 text, marked up in XHTML and expanded to include the cross product of date/time/dateTime and lexical/compact/full/minimal. I have posted a prototype implementation at http://en.wikibooks.org/wiki/Talk:XForms/Formatting_a_date Unfortunately JavaScript Date does not provide a way of getting long, medium, and short date formats as do some other localization systems, so the task of localized formatting must be left to someone who better understands how to obtain this information from the Mozilla framework.
I believe this example applies to both XForms 1.0 and 1.1 because the normative text did not change; only an example was added. This is an expanded version of the example, marked up in XHTML.
Attachment #256200 - Attachment mime type: application/xml+xhtml → application/xhtml+xml
(In reply to comment #8) > Mozilla XForms already uses appearance='full' to show a mostly static > calendar chooser for xsd:date. (It has a bug: it allows you to change > the month, even though it's an output.) > I'm fine to use appearance attribute to format date value for output. I guess we can stop to use full appearance to show calendar and use for example 'calendar' appearance if Aaron is ok with this. There is registered in bugzilla bug 339082 that is related with mentioned issue. Though I'm still not sure it's a bug since bound node value isn't changed.
(In reply to comment #10) > (In reply to comment #8) > > > Mozilla XForms already uses appearance='full' to show a mostly static > > calendar chooser for xsd:date. (It has a bug: it allows you to change > > the month, even though it's an output.) > > > > I'm fine to use appearance attribute to format date value for output. I guess > we can stop to use full appearance to show calendar and use for example > 'calendar' appearance if Aaron is ok with this. That's fine with me. > > There is registered in bugzilla bug 339082 that is related with mentioned > issue. Though I'm still not sure it's a bug since bound node value isn't > changed. > I'd say it is a bug. It gives the user the illusion that they are making changes when they really aren't.
Attached patch patch (obsolete) — Splinter Review
it doens't work due to security reasons, unprivileged content cannot create XPCOM components. Probably conversion code may be moved into xtf part.
Attached patch patch2Splinter Review
this version works in privileged content
Attachment #256345 - Attachment is obsolete: true
The XForms rec is going to be mute on the actual appearances of output/@appearance and I don't intend to say otherwise. If your users like the calendar for full there's no reason you can't satisfy their needs. But there ought to be at least one localized plaintext one and then of course output/[not @appearance] should be lexical.
Aaron, Leigh is right. Probably someone uses already our calendar as full output :). So we should ask on NG should we continue to hold those appearance for calendar. Or at least we should notify them that we like to stop this.
I'm not working on this anymore.
Assignee: surkov.alexander → nobody
RIP xforms
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: