Changes to make Extensible ready for other types of calendar #58

ziadloo · 2013-06-26T14:04:23Z

While I was trying to add Jalali calendar to Extensible Calendar I came across couple of changes to the core. As you can see these changes are completely safe and has no affect on the original code. I've also added a locale file for Farsi. To be able actually use the Jalali calendar some changes must also be made to ExtJS's Farsi locale file. Things like Ext.Date.formatFunctions and Ext.Date.parseFunctions which I didn't include here. Perhaps I should send ExtJS project a pull request as well!

To explain the modifications to Extensible.Date class; getDate and getMonth methods of JS's original Date class are moved to Extensible.Date so they can be override in locale file.

There's also a date format added to calendar panel: jumpToDateFormat

BTW, Jalali calendar's week starts with Saturdays hence the startDay: 6 in locale file. I see there's been a bug 355 reported and startDay configuration is not applied correctly and it seems to be fixed. But my experience states otherwise, no matter what I can not set the startDay of the CalendarPanel component. Please let me know if this bug has been taken care of. Thanks.

This change is

gsidler · 2013-07-17T17:34:35Z

Hi ziadloo,
Bug 355 was fixed in version 1.6.0 Beta but not in the latest production release 1.5.3. Which version are you using?

Gabe

bmoeskau · 2013-07-18T17:17:13Z

I've had a chance to look at this a bit -- thanks for the translations! Regarding the date methods, I would be more inclined to have the locale file override the native Date getDate and getMonth methods (and any other methods that might come up later) rather than adding extra date methods to Extensible and changing internal code. While the changes look OK, that approach won't scale very well as other locales might need similar, but different, types of overrides to the Date object. Any such overrides would need to apply anywhere the affected Date methods are used, so probably better just to override Date directly than add a layer of indirection + potential for bugs if anyone ever forgets to use the special methods. Thoughts?

ziadloo · 2013-07-18T18:20:24Z

@brian: I understand your concern for introducing a wrapper around Date object, but I must tell you it's inevitable. If we implement this your way we will lose JavaScript's original Gregorian Date object. Here's how other calendars are implemented in a software; all dates are stored and manipulated in Gregorian (since it is supported by all sorts of software) and are only converted to other types of calendars just before they are shown to the user. So we need to have the javascript's original Gregorian date intact and convert them to other types through a wrapper. Let me know if you don't find this sufficient reason for using a wrapper, I don't want to brag about myself but I'm pretty experienced in this matter and I don't see a way around it. I've also searched all of Extensible's code and replaced all the instances with the wrapper.

ziadloo · 2013-07-18T18:27:14Z

@gabriel: I've fork the master branch, you see for yourself. https://github.com/ziadloo/Extensible . What I'm saying is that the problem exists in 1.60 beta (unfortunately).

bmoeskau · 2013-07-18T18:46:51Z

@ziadloo Looking further, I assume that you mean the issue is with this code inside the Jalali calendar code, which requires the original Date methods to work as expected:

g = [
    date.getFullYear()
    , date.getMonth() + 1
    , date.getDate()
];

Also, for my own understanding, how does this work with the Jalali class still returning a standard Date object as output? I would assume that it would return a wrapper class of its own (similar to how it already implements a today() method) instead of relying on the underlying Gregorian calendar? How does it work when you call getDate() on the Date object returned from this class, doesn't it return the default Gregorian value still?

ziadloo · 2013-07-18T19:17:54Z

@bmoeskau: No, I'm not just talking about Jalali converter code, you need to consider all sorts of libraries / components designed around the world which rely on Gregorian calendar. That's how you can get the whole picture. If you convert the date when printing it as output and when getting it as input (i.e. G2J and J2G) then you can rest assure that the rest of world will work with your code once they can work with Gregorian.

The Jalali class is not a wrapper for Date class. It's simply a global object with two (static) functions: g2j and j2g. While j2g returns an ordinary JavaScript Date object, g2j returns a simple array containing [year, month, day]. 'today' is just a handy method to get today's date in Jalali calendar, it is not meant to override JS Date's method (as Jalali class does not inherit from JS Date class).