[#4203] - RFC: Change to Datepicker / Calendar Fields
- Closed
- 7 Sep 2015
- Medium
- Build: staging
- # 4203
- Diff
- purplebeanie:dtpickerfields
- Error The Travis CI build could not complete due to an error Details
User tests: Successful: Unsuccessful:
I'm a little nervous to fire off this PR as it turned out to to be a lot more complicated than I first thought.... But here goes.
This PR will need more work before it is ready but I wanted to get some feedback from others on the approach I have taken with the languages and the best way to demonstrate was with code. I have put some discussion questions at the end which was where I was seeking most feedback.
The problem I'm trying to solve
- The current Joomla calendar picker is quite old, and based on feedback from an earlier question to the devcms list does not natively have support for non-Gregorian calendars.
- The current Joomla calendar picker has a fairly weak time picker that is not enabled, and currently cannot be turned on without changing the calendar behaviour.
The calendar I have used
A user on the CMS list (Elvis) turned up the Keith Woods calendar picker from here (http://keith-wood.name/calendarsPicker.html). This is a modern, maintained calendar picker that includes:
- Support for RTL
- Support for non-Gregorian calendars
- Extensive localisation already done out of the box
- A good underlying calendaring JS library to allow conversions from one calendar to another
The approach I have taken
After feedback from @Bakual I have included ALL calendars and localisation files as part of the base PR. The relevant language and localisation file is then loaded based on the language.
This PR introduces a new attribute to the Calendar form field XML caltype. This is set to one of the calendar types that the Keith Wood jQuery calendar plugin has support for. See the files in /media/calendar/js for complete listing. By default these are named jquery-calendars.persian.js etc.
If no caltype is specified a Gregorian calendar will be used.
Presently if using a calendar type other than Gregorian the conversion is done on the client side and the dates converted. I found doing some conversion on the server and some on the client resulted in drift due to the Browser time zone. Conversion needs to be done either all on the server, or all on the client. The reason for choosing client meant that the changes could all be contained within the JS injected by the Calendar behaviour.
To test
Install this PR and go to a content item.
Focus on or click the button beside a calendar field and the new calendar picker will popup. This is the redmond theme which seemed the closest match for the present Joomla admin. There are a few css fixes in /media/calendars/css/joomla-css-fixes.css
To use with a different language install the relevant Joomla language pack and login using the desired language. The calendar will load the correct localisation pack based on the language. These are from the calendar picker widget so may not be the same as the calendar strings defined in the Joomla language file.
To use with a different calendar open the form xml and add a caltype="persian" to the form attribute. For example if using a content article from administratator open administrator/components/com_content/models/forms/article.xml and for arguments sake set the created field to:
<field name="created" type="calendar" label="COM_CONTENT_FIELD_CREATED_LABEL"
description="COM_CONTENT_FIELD_CREATED_DESC" size="22"
format="%Y-%m-%d %H:%M:%S" filter="user_utc" caltype="persian" />
A note for testing ** when loading the JS files using JHtml::_('script') I have used the / instead of the DIRECTORY_SEPERATOR constant. Is this okay or will this cause breaks? I also test for a file path using if (!file_exists(JPATH_BASE.'/media/calendars/js/jquery-calendars-'. $langTag .'.js')) again is this okay? or will they break on Windows?
Discussion Questions
- Presently the calendar is swapped per field based on using the caltype attribute in the form XML. Is this the best way?
- Is there a reason why a user would want to have several different calendar types in a form or should I swap this based on the user language as well?
- Is it safe to define a calendar based on language type? Would a Persian user for example want to use a Gregorian calendar?
- Is client side JS the best place to do conversion to / from Gregorian and chosen calendar?
jissues-bot
- | Labels |
Added:
?
|
||
Thanks @infograf768 . I wasn't sure the best way to handle the calendar type setting. I wasn't sure whether I could assume a mapping from language => calendar type.
I will modify to force calendar type selection based on the language.
Currently the only missing languages I could identify are:
- Belarusian
- Central Kurdish
- Sinhala
- Syriac
- Uyghr
Having review the list of languages I will also need to review the way the language files are loaded. Presently I was just pulling the language tag using JFactory::getLanguage()->getTag() and then appending that to a file name to load the localisation pack. There are discrepancies between the language tags however and the way the files have been named so I will need to change the loading to do a look up on an assoc array for the language tag to get the file name.
Regarding 1.1MB none of the JS or CSS is currently compressed. So would compressing and then making the uncompressed available as a separate download be a workable solution?
The other thing is that CSS is included for themes that are not used. I am using the Redmond theme so the CSS for other themes could also be removed.
Eric.
Thanks for this PR!
As Jean-Marie already said the calendar at least by default should be chosen based on the active language. Currently, that's achieved with overrides of the JavaScript.
@infograf768 Would it maybe possible that we can introduce a new attribute to the language xml file (https://github.com/joomla/joomla-cms/blob/staging/language/en-GB/en-GB.xml) which specifies the calendar?
I'm not to much concerned about the file size. Usually we provide compressed and uncompressed ones together, while the compressed one is used regulary and the uncompressed are used when debug is turned on. JHtml::script does detect that automatically.
If there are unused files, we can of course ommit them.
@infograf768 Would it maybe possible that we can introduce a new attribute to the language xml file (https://github.com/joomla/joomla-cms/blob/staging/language/en-GB/en-GB.xml) which specifies the calendar?
That is what I proposed above, as anyway some stuff, if we use this proposal, would be obsolete : Weekday, First Day for example)
It would be even more customizable if it was depending from a metadata setting in the language xml.
So for example, Thai pack could propose the Thai Calendar (Budhist) or Julian if they wish by using
<calType> </calType>
in the xml.
Now, concerning the UI language files themselves, we had managed until now to map js strings to ini strings for calendar. It would be great if we could do the same with this new calendar.
See
protected static function calendartranslation()
in
https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/html/behavior.php
Thanks @infograf768, @Bakual . I will experiment with this over the next day or so and update the PR when done.
brianteeman
- | Category | ⇒ | Multilanguage |
Regardless of how this is implemented further, could you please look at the results of travis and fix those? Start by pulling in the latest changes to staging and then work your way from there on up.
Hello @purplebeanie
Thank you for your contribution.
The last comment here was on 3rd February. So the question is, Is this issue/pull request still valid?
If no reply is received within 4 weeks we will close this issue.
Thanks for understanding!
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4203.
| Status | Pending | ⇒ | Information Required |
Hey @roland-d and @Hackwar .... It sort of fell in a hole for a while. I changed github accounts and then got slammed with study and work commitments.
The goal was to swap out the old dhtml datetime picker -- the current Joomla calendar picker -- to something more modern that still had support for all the different calendars that Joomla needs to support.
So yes, I will refresh this and do some work to make Travis happy. I should have some time free week after next to get onto this one.
It's up to you folks if you'd prefer to close this PR and I can re-open another one when I've had a chance to fix it up?
Eric.
Hey Eric,
Thank you for the follow-up. I am happy to leave this open longer, a few more weeks won't matter. Looking forward to your changes.
zero-24
- | Labels |
Added:
?
|
||
joomla-cms-bot
- | Labels |
Added:
?
|
||
Hey Folks,
I am closing this PR. After reviewing over the weekend it needs a little more TLC than I've got time to give until after college ends for the year (13th November).
I will work on it again then and re-open the PR then based on whatever is current at mid November.
Cheers,
Eric.
| Status | Information Required | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-09-07 23:56:06 |
| Closed_By | ⇒ | purplebeanie |
We just can't change all xmls to get a calendar type like Jalali for Persian. This has to be automatic depending on the language used. Therefore it should be based on the language tag (fa-IR for example).
It would be even more customizable if it was depending from a metadata setting in the language xml.
For the UI itself, are all Joomla languages included? Can you post a list of those missing?
NOTE: This adds 1.1 MB to Joomla package