Closed
Bug 331585
Opened 19 years ago
Closed 9 years ago
Output that shows date/dateTime in current locale
Categories
(Core Graveyard :: XForms, enhancement)
Core Graveyard
XForms
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: allan, Unassigned)
References
()
Details
Attachments
(2 files, 1 obsolete file)
2.48 KB,
application/xhtml+xml
|
Details | |
9.74 KB,
patch
|
Details | Diff | Splinter Review |
How about including an output with appearance="?" that "prettyprints" a date/time/dateTime in the current locale, like "February 2nd 2005"?
Reporter | ||
Updated•18 years ago
|
Assignee: aaronr → xforms
Comment 1•18 years ago
|
||
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
Comment 2•18 years ago
|
||
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
Comment 4•18 years ago
|
||
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.
Comment 6•18 years ago
|
||
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.
Comment 7•18 years ago
|
||
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.
Comment 8•18 years ago
|
||
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.
Comment 9•18 years ago
|
||
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.
Updated•18 years ago
|
Attachment #256200 -
Attachment mime type: application/xml+xhtml → application/xhtml+xml
Comment 10•18 years ago
|
||
(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.
Comment 11•18 years ago
|
||
(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.
Comment 12•18 years ago
|
||
it doens't work due to security reasons, unprivileged content cannot create XPCOM components. Probably conversion code may be moved into xtf part.
Comment 13•18 years ago
|
||
this version works in privileged content
Attachment #256345 -
Attachment is obsolete: true
Comment 14•18 years ago
|
||
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.
Comment 15•18 years ago
|
||
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.
Comment 17•9 years ago
|
||
RIP xforms
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•