[OpenAjaxIDE] date formatting
Adam Peller
apeller at us.ibm.com
Thu Aug 20 13:04:41 PDT 2009
What is the scope for these tags? If they don't get their own unique
scope, you could always hide it in a closure.
Bertrand Le Roy
<Bertrand.Le.Roy@
microsoft.com> To
Adam Peller/Cambridge/IBM at IBMUS,
08/20/2009 01:28 Jon Ferraiolo/Menlo Park/IBM at IBMUS
PM cc
"ide at openajax.org"
<ide at openajax.org>
Subject
RE: [OpenAjaxIDE] date formatting
Do we have precedent of that sort of thing in the spec?
How do you handle multiple instances of the same widget (or multiple
widgets using the same code)? It will be wasteful and even an error in
strict mode to define the same function or variables multiple times.
From: ide-bounces at openajax.org [mailto:ide-bounces at openajax.org] On Behalf
Of Adam Peller
Sent: Thursday, August 20, 2009 9:03 AM
To: Jon Ferraiolo
Cc: ide at openajax.org
Subject: Re: [OpenAjaxIDE] date formatting
alternatively:
<property name='mindate' datatype='Date' format='date'/>
<javascript location="afterContent">
function yuiFormat(d){return mdate.getMonth()+"/"+mdate.getDay
()+"/"+mdate.getFullYear(); }
var calwidget = new YAHOO.whatever.calendar({...mindate:yuiFormat
(@@mindate@@)...});
</javascript>
which I think reads pretty well. One open issue is whether we'd be dealing
with UTC or local time once the substitutions take place. I suspect we'll
have to work in UTC to be consistent. (Granted, it's a JS gotcha, but we're
not out to eliminate all of those)
Inactive hide details for Jon Ferraiolo---08/20/2009 11:17:08 AM---If we
add another attribute, its name should reflect that thJon
Ferraiolo---08/20/2009 11:17:08 AM---If we add another attribute, its name
should reflect that the attribute only applies to formatting dates versus
other datatypes
Jon
Ferraiolo/Men
lo
Park/IBM at IBMU
S To
Sent by:
ide-bounces at o "ide at openajax.org"
penajax.org <ide at openajax.org>
cc
08/20/2009
10:56 AM
Subject
Re: [OpenAjaxIDE]
date formatting
If we add another attribute, its name should reflect that the attribute
only applies to formatting dates versus other datatypes. Therefore, instead
of 'formatString', the attribute should be named something like
'formatDate', 'dateFormat' or 'dateResultFormat'. (The latter one is long,
but re-inforces that we are formatting on the property editor result rather
than the input value that is given the property editor.)
But like Adam I would like to see side-by-side comparisons of how the OAM
file would look if we added a new attribute versus pushing this feature
into something that has to be done via JavaScript. I'll take a crack at it.
With a 'dateResultFormat' attribute:
<property name='mindate' datatype='String' format='date'
dateResultFormat='MM/DD/YYYY'/>
<javascript location="afterContent">
var calwidget = new YAHOO.whatever.calendar({...mindate:@@mindate@@...});
</javascript>
Without a 'dateResultFormat' attribute:
<property name='mindate' datatype='Date' format='date'/>
<javascript location="afterContent">
var mdate = @@mindate@@;
var mdate_string = mdate.getMonth()+"/"+mdate.getDay
()+"/"+mdate.getFullYear();
var calwidget = new YAHOO.whatever.calendar({...mindate:mdate_string...});
</javascript>
Jon
Inactive hide details for Lori Hylan-Cho ---08/19/2009 10:41:14 PM---I
agree with Kin that we shouldn't make widget developers Lori Hylan-Cho
---08/19/2009 10:41:14 PM---I agree with Kin that we shouldn't make widget
developers (or oam.xml file writers, who may not be
From: Lori Hylan-Cho <avocadoh at gmail.com>
To: Jon Ferraiolo/Menlo Park/IBM at IBMUS
Cc: Kin Blas <jblas at adobe.com>, "ide at openajax.org"
<ide at openajax.org>
Date: 08/19/2009 10:41 PM
Subject: Re: [OpenAjaxIDE] date formatting
I agree with Kin that we shouldn't make widget developers (or oam.xml file
writers, who may not be the same people) write extra JS when we can include
a declarative format in the spec.
I agree with Jon and Scott that a separate attribute for the format string
should be used for the reason Jon outlined.
As regards encouraging bad coding practices, I'd rather recognize reality
and give dev tools a chance to support it than try to get everyone to
conform to an ideal.
Lori
[brevity brought to you by iPhone.]
On Aug 19, 2009, at 9:55 PM, Jon Ferraiolo <jferrai at us.ibm.com> wrote:
After thinking about things, I don't like either of
the following:
format="d/m/Y"
or
format="date(d/m/Y)"
The 'format' attribute tells the tool what type of
special editor to display within the property
editor in order for the user to enter a value. For
example, a tool might provide a calendar widget to
edit a property that has format="date", a clock
dial widget to edit a property that has
format="time", and a color picker widget to edit a
property that has format="color". I don't think we
want to try to co-mingle the formatting
instructions into the same attribute that provides
a hint about which editor widget to use within the
property editor UI.
If we are going to offer date formatting, I think
an additional attribute such as what Scott has
proposed is the way to go.
Regarding whether we should include this feature or
not, I won't object if the majority think this is a
necessary feature for version 1.0, but at the
moment I'm not sold that this is an appropriate
feature for the spec. Two things worry me:
(1) So far, I haven't seen any JavaScript-free OAM
files for OAM files that wrap widgets from Ajax
toolkits. If OAM authors need to resort to
JavaScript anyway, then for the YUI calendar widget
(and similar calendar widgets), the widget
developer working on the calendar widget can figure
out how to format the date values (perhaps by
including Steve's 40 lines of JavaScript within
that particular widget)
(2) I'm not sure that it is compelling easier for a
widget developer to discover and learn how to use
the 'formatString' attribute versus writing a
little JavaScript to create the appropriate string
before calling the constructor.
But nevertheless, if the majority want this
feature, I'm OK with adding it as Scott proposes
below.
Jon
<graycol.gif>Kin Blas ---08/19/2009 03:21:31
PM---For the datatype="Date" there are 2 supported
format values, "date" and "time": <property
name="myDa
<ecb <ecblank.gif>
lank Kin Blas <
.gif jblas at adobe.com>
>
From
:
<ecb <ecblank.gif>
lank "ﾅide at openajax.org"
.gif <㔰ide at openajax.org>
>
To:
<ecb <ecblank.gif>
lank 08/19/2009 03:21 PM
.gif
>
Date
:
<ecb <ecblank.gif>
lank Re: [OpenAjaxIDE]
.gif date formatting
>
Subj
ect:
<ecb <ecblank.gif>
lank ide-bounces at openajax
.gif .org
>
Sent
by:
For the datatype=”Date” there are 2 supported
format values, “date” and “time”:
<property name=”myDate” datatype=”Date”
format=”date” />
<property name=”myTime” datatype=”Date”
format=”time” />
Rather than introducing another attribute, as
proposed in Scott’s example. Why not just leverage
the existing @format attribute in conjunction with
the variables used by PHP:
http://us.php.net/manual/en/function.date.php.
The current proposed values for the Date @format
aren’t that useful in my opinion. So I envision
something like:
<property name=”myDate” datatype=”Date”
format=”d/m/Y” />
<property name=”myTime” datatype=”Date”
format=”g:i:s” />
Regarding Jon’s comment about being able to work
around this problem with additional code added to
the <javascript> or <content> sections … I really
feel that if we want this OAM format to be adopted
by the various frameworks and the industry, that we
need to make it drop-dead simple for them to
support their formats/patterns so they don’t have
to resort to writing extra-glue code to make up for
our in-flexibility.
--== Kin ==--
From: ide-bounces at openajax.org [
mailto:ide-bounces at openajax.org.] On Behalf Of
Scott Richards
Sent: Wednesday, August 19, 2009 3:00 PM
To: Steve Repetti; 'Jon Ferraiolo';
ide at openajax.org
Subject: Re: [OpenAjaxIDE] date formatting
I think a lightweight solution that supports a very
small set of legacy formats would be all we need.
Sounds like Steve’s 40+ lines of DateFormat code
could handle this.
I like a simple approach of adding an additional
formatString=”” attribute or maybe call it
formatPattern that enables you to format in the
value that is replaced using the @@variableName@@
notation in either the <javascript> or <content>
sections. Here is an example.
<property datatype=”date” format=”date”
formatString=”YYYY-MM-DD” />
where:
YYYY = four-digit year
MM = two-digit month (01=January, etc.)
DD = two-digit day of month (01 through 31)
hh = two digits of hour (00 through 23) (am/pm NOT
allowed)
mm = two digits of minute (00 through 59)
ss = two digits of second (00 through 59)
The formats from YUI Calendar takes Javascript Date
Object or a string formatted as “mm/yyyy” and
“mm/dd/yyyy”. The selected property can only be
specified with a string not a Javascript date
object and it does not support ISO 8601 format. See
this link
http://developer.yahoo.com/yui/calendar/#config
Here is an example of how we could support YUI
Calendar date strings using formatString.
var cal1 = new YAHOO.widget.Calendar("cal1",
"cal1Container",
{ pagedate:"5/2007",
selected:"5/5/2007-5/27/2007" });
This would look like the following in the oam.xml
file:
<javascript>
var cal1 = new YAHOO.widget.Calendar("cal1",
"cal1Container",
{ pagedate:"@@pageDate@@",
selected:"@@selectDateStart@@-@@selectDateEnd@@" });
</javascript>
<property
name=”pageDate” datatype=”date” format=”date” formatString=”MM/YYYY” />
<property
name=”
selectDateStart”
datatype=”date” format=”date” formatString=”MM/DD/YYYY” />
<property
name=””
selectDateEnd”
datatype=”date” format=”date” formatString=”MM/DD/YYYY” />
Not sure if we should support dropping out leading
0’s, do we need to support this? We could do with
just M or D. But the YUI calendar works specifying
dates with or without leading 0’s. So this may be
unnecessary.
Here is the link for jQuery Date formats. They
support multiple formats including iso 8601. So
with could support it as follows:
_______________________________________________
IDE mailing list
IDE at openajax.org
http://openajax.org/mailman/listinfo/ide
_______________________________________________
IDE mailing list
IDE at openajax.org
http://openajax.org/mailman/listinfo/ide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20090820/3cd1133b/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20090820/3cd1133b/attachment-0003.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic19547.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20090820/3cd1133b/attachment-0004.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20090820/3cd1133b/attachment-0005.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0C229106.jpg
Type: image/jpeg
Size: 168 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20090820/3cd1133b/attachment-0003.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0C139992.jpg
Type: image/jpeg
Size: 166 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20090820/3cd1133b/attachment-0004.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0C935464.jpg
Type: image/jpeg
Size: 168 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20090820/3cd1133b/attachment-0005.jpg
More information about the IDE
mailing list