PDA

View Full Version : [Ext 2.0] Ext.ux.MagicDate



ElliotS
1 Oct 2007, 10:41 PM
Based on 'A better way of entering dates (http://simonwillison.net/2003/Oct/6/betterDateInput/)' by Simon Willison this is a new class that will allow a user to enter many date formats as well as plain english.

Some examples :

today
tomorrow
yesterday
next week
last year
3 days ago
2 years from now
next tuesday


It also has a long list of date patterns which are also checked.

I am registering MagicDateField as the default date field using

Ext.reg('datefield', Ext.ux.MagicDateField);
so it requires no changes to existing applications.... (as long as you use xtype ;P)

An example of adding a custom regexs


Ext.ux.MagicDate.regex.push(
// Elliot's birthday
{
re: /^elliot/i,
handler: function(bits) {
return Date.parseDate('29/11/1983', 'd/m/Y');
}
}
);

Ext.ux.MagicDate.regex.push(
// Start of current financial year
{
re: /^sf/i,
handler: function(bits) {

var now = new Date();
var sofy = Date.parseDate("Jul", "M").getFirstDateOfMonth();

if (now < sofy) {
sofy.setFullYear(sofy.getFullYear() - 1);
}

return sofy;
}
}
);


By default it is using european style dates (I'm an Aussie), but I've included commented out american style.

I'd love to hear any feedback or bugs.... otherwise enjoy! Trust me, clients will be impressed ;)

BTW if you just wanted more date patterns (without the regular expressions)... you could just do

Ext.form.DateField.prototype.altFormats = Ext.ux.MagicDate.patterns.join('|');

brian.moeskau
1 Oct 2007, 11:49 PM
Nice idea! I haven't tested the code directly, but glancing through it, are you missing this at the end of your switch statement?


case 'thirty': bits[1] = 30; break;

To handle 30 and 31? It would be real nice if the strings could be factored out of the code for locale support, but for this class, based on how regexes are used, that would probably make it hopelessly complex. For English speakers though, this should be a great extension.

ElliotS
2 Oct 2007, 1:38 AM
The regexes weren't done by me, I just included them =)
I'll make whatever cleanups people can come up with.

jack.slocum
2 Oct 2007, 3:14 AM
For the regexs you can do:

new RegExp('today', 'i'); instead of /today/i and then take it to the next step:

Ext.ux.MagicDate.today = 'today';

then:

re: new RegExp(Ext.escapeRe(Ext.ux.MagicDate.today), 'i')

The a locale file could exist like the standard Ext locale files.

JeffHowden
2 Oct 2007, 8:34 AM
There are certain aspects of Simon's work that are broken, including no support for times. I've implemented my own versions of this in a non-Ext environment. I'd love to collaborate on this to produce a highly polished version for Ext.

ElliotS
2 Oct 2007, 4:19 PM
There are certain aspects of Simon's work that are broken, including no support for times. I've implemented my own versions of this in a non-Ext environment. I'd love to collaborate on this to produce a highly polished version for Ext.

Brilliant! It doesn't sound like you need much help but I'd be happy to provide what I can. It would be good to have a clean implementation anyway because of the licensing (and it would be nice to have it included with ext ;)

kfuglsang
17 Oct 2007, 12:00 AM
I for one would love to have a localized version of this; We are about to start working on a web-interface for our ERP-system that has similar functions in date-fields - if I could emulate these on the web it'd be really great!

Hoping to see updates to this!

Best regards
Kenneth
Denmark

ElliotS
17 Oct 2007, 9:24 PM
I for one would love to have a localized version of this; We are about to start working on a web-interface for our ERP-system that has similar functions in date-fields - if I could emulate these on the web it'd be really great!

Hoping to see updates to this!

Had to jump back to Java-land for a while... but I'll try and get a much cleaner release out this weekend. Glad to see it might be used =)

mystix
25 Oct 2007, 6:19 AM
:D how did i ever miss this thread??? nice find =D>



There are certain aspects of Simon's work that are broken, including no support for times. I've implemented my own versions of this in a non-Ext environment. I'd love to collaborate on this to produce a highly polished version for Ext.

i'm in. ;)

DigitalSkyline
12 Feb 2008, 4:29 PM
Has there been any changes/progress on this?

Troy Wolf
13 Feb 2008, 6:26 AM
I am interested in any utilities that make entering and validating times easier. For example, I have an application where the user needs to enter a range of minutes where the values may be: 11:04 to 11:07.

I've subscribed to this thread in hopes Jeff finds the time/motivation/encouragement to develop his idea into something the community can use. ~o)

mystix
13 Feb 2008, 9:09 AM
tried http://www.datejs.com/ ?

looks interesting. plus there's detailed instructions on getting it to work with Ext:
http://groups.google.com/group/datejs/browse_thread/thread/b343b2eb7372405c/d7eff63a47a0127f?lnk=gst&q=ext#d7eff63a47a0127f

ram
13 Feb 2008, 11:33 AM
I would love to see datejs (http://www.datejs.com) integrated. There's options for date parsing, formatting and date arithmetic in there that would be pretty useful.

Or to avoid the dependancy, it would be great if ExtJS supported pluggable date interface to allow integration by the users.

Animal
14 Feb 2008, 1:19 AM
Shouldn't this be an enhancement, or a plugin to the regular date parsing code.

I like the idea, and we have a similar scheme added to our date fields to allow "today", "tomorrow", "n[ext] m[onday]" "fdnm" (first day of next month) "-3" (three days ago) "-2y" (2 years ago) etc etc. So an internationalized, native Ext version of this would be great. It would probably shrink our codebase.

Troy Wolf
14 Feb 2008, 6:07 AM
Shouldn't this be an enhancement, or a plugin to the regular date parsing code.

I like the idea, and we have a similar scheme added to our date fields to allow "today", "tomorrow", "n[ext] m[onday]" "fdnm" (first day of next month) "-3" (three days ago) "-2y" (2 years ago) etc etc. So an internationalized, native Ext version of this would be great. It would probably shrink our codebase.

+1 ~o)