Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

All other Modules /

Discuss all other Modules here.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Preview: Event Calendar Module


Go to End


293 Posts   69237 Views

Avatar
bummzack

Community Member, 904 Posts

3 April 2009 at 9:44pm

Edited: 03/04/2009 9:49pm

Hi UncleCheese

Thanks for your work on the CalendarModule. The dmy Dates work just fine.
However, I think you'll encounter problems when this module will be widely used, because there are far more date-formatting conventions/styles than just dmy and mdy.

That's why I suggested a template approach instead of the if(dmy) else (mdy). I have thought about this and I would suggest something like the following:
- Create a translatable String for all the different Date-outputs (eg. one day, same month and year, different months etc.)
- These Strings must consist of pre-defined placeholders which will then be replaced by a simple str_replace

Here's how this could look in code:

// example for the getDateString method, same year but different month
// first we get the localized template. Per default we use a american mdy template
// the advantage of this approach is, that every language/localization can have a custom date template
$template = _t(
    'EVENTCALENDAR.diffMonthSameYear', 
    '%{sDayNum}%{sDaySuffix} %{sMonShort} - %{eDayNum}%{eDaySuffix} %{eMonShort}, %{eYearFull}'
);

// array of placeholders. This array should contain all possible variations of
// day, weekday, month, year output
// This won't change it could be a static member of the class
$placeHolders = array(
    '%{sWeekDayShort}',
    '%{sWeekDayFull}',
    '%{sDayNum}',
    '%{sDaySuffix}',
    '%{sMonNum}',
    '%{sMonShort}',
    '%{sMonFull}',
    '%{sYearShort}',
    '%{sYearFull}',
    '%{eWeekDayShort}',
    '%{eWeekDayFull}',
    '%{eDayNum}',
    '%{eDaySuffix}',
    '%{eMonNum}',
    '%{eMonShort}',
    '%{eMonFull}',
    '%{eYearShort}',
    '%{eYearFull}'
);

// populate the replacement array
$replacement = array(
    strftime('%a',  $start), // sWeekDayShort
    strftime('%A',  $start), // sWeekDayFull
    date    ('d',   $start), // sDayNum
    date    ('S',   $start), // sDaySuffix
    date    ('m',   $start), // sMonNum
    strftime('%b',  $start), // sMonShort
    strftime('%B',  $start), // sMonFull
    date    ('y',   $start), // sYearShort
    date    ('Y',   $start), // sYearFull
    
    // now the same for the end date
    strftime('%a',  $end), // eWeekDayShort
    strftime('%A',  $end), // eWeekDayFull
    date    ('d',   $end), // eDayNum
    date    ('S',   $end), // eDaySuffix
    date    ('m',   $end), // eMonNum
    strftime('%b',  $end), // eMonShort
    strftime('%B',  $end), // eMonFull
    date    ('y',   $end), // eYearShort
    date    ('Y',   $end), // eYearFull
);

// now all that's left to do is to replace the placeholders in the template
$formattedDate = str_replace($placeHolders, $replacement, $template);

I think this would be a really flexible and extensible approach for the localization problem.
What remains an issue is the localization of the datePicker widget. Maybe you could bundle the localizations that are provided by the widget author: http://jqueryjs.googlecode.com/svn/trunk/plugins/methods/ and include them according to the locale.
Another possibility would be to generate the required javascript automatically. If you look at these localization files they are really simple and could be generated with only using the strftime function.

Another thing that bugs me are the requirements.. yeah, still. I'd really move them to the template files :)

Sorry for length. If you wish, I can implement the date template approach and provide a patch. Most likely you know better where adjustments have to be made though.

Best - Roman

Edit: Ugh. Code formatting turns out really ugly even when using spaces instead of tabs. A developer forum should at least have some usable code parser/formatting. Anyway.. here's a pastebin link: http://pastebin.com/m2a451393

Avatar
bummzack

Community Member, 904 Posts

3 April 2009 at 10:53pm

I'm not sure if this is a bug, but somehow the Times output seems to be broken in the latest SVN release.
I can't tell if that worked in the previous versions, because I noticed just now.

Avatar
UncleCheese

Forum Moderator, 4102 Posts

4 April 2009 at 2:30am

@dreamstudio - The bugs you're reporting sound like issues that were resolved a few revisions back. Can you make sure you're on the latest SVN and if so, please replicate the issues you're experiencing on the demo site, eventcalendar.bluehousegroup.com, so I can test. Please be as specific as you can. I only get a few hours to put into the eventcalendar every day, so the less guess work I have to do the quicker I can fix the problem. Thanks.

@banal - I'm going to review your code. I did have something like this in mind, I just want to make sure I don't lose any of the functionality I had already baked in. Looks good, though. Re: the Times control, it's gone. It only worked half the time, anyway. I need a new solution for that. I'm thinking about writing a module that would allow basic has_many relation management within a popup window, which would allow management of many CalendarDateTime objects with their own set of Time objects. Other than that, the best solution i can come up with for multiple times is to parse a string with expected delimiters. 8:00-9:00//10:00-12:00//3:30-5:00... but that's really cheap.

Avatar
UncleCheese

Forum Moderator, 4102 Posts

4 April 2009 at 2:42am

Banal, it definitely looks like you're on to something here. A few questions:

- Where does one create his custom date template? And what would that look like? (I've never had to deal with translations)

- What if a user wants to opt of out some of these date components, e.g. "day suffix"? What about adding components like dayOfWeek? (e.g. Monday)

- The reason I haven't migrated the requirements to the template is because the CalendarWidget has its own requirements, so it's nice to just run $CalendarWidget and not have to worry about including script

Unless, we change the forTemplate() method to something like $this->renderWith('CalendarWidget'), and we do the require tags there. Ahh.. I like it.

Avatar
dreamstudio

Community Member, 48 Posts

4 April 2009 at 2:45am

Cheese, where is the best place to get the most upto date version as I downloaded the r7 module from the silverstripe module site.

Avatar
UncleCheese

Forum Moderator, 4102 Posts

4 April 2009 at 2:51am

At this point i wouldn't recommend using the download. Changes are coming in so fast, you're best off using SVN. There's an SVN url provided on the event_calendar download page. It's:

http://carlinowebdesign.svn.beanstalkapp.com/modules/trunk/event_calendar

Avatar
dreamstudio

Community Member, 48 Posts

4 April 2009 at 3:03am

Tried to get it on that location and it says it doesnt exist... can get other svn files ok usually

Avatar
bummzack

Community Member, 904 Posts

4 April 2009 at 3:03am

Edited: 04/04/2009 3:04am

Hi UncleCheese

The translations are usually stored in the "lang" subfolder of a module. There you have the .php Files for the different languages, each of them containing an array with translated entries.
In en_US.php you'd probably put something like:

$lang['en_US']['EVENTCALENDAR']['diffMonthSameYear'] = '%{sMonShort} %{sDayNum}%{sDaySuffix} - %{eMonShort} %{eDayNum}%{eDaySuffix}, %{eYearFull}';

Whereas in de_DE.php you could have:

$lang['de_DE']['EVENTCALENDAR']['diffMonthSameYear'] = '%{sDayNum}. %{sMonShort}. - %{eDayNum}. %{eMonShort}., %{eYearFull}';

Of course you'd have to create a translation entry for all of your date-output needs. "diffMonthSameYear" would be for the case where the months are different, but the year changes. Other than that you'll need "diffMonthDiffYear" etc.. So basically all the cases you have in CalendarUtil::getDateString().
You should define as many Placeholders as possible for greatest flexibility. For example the %{sDaySuffix} will only be useful for english locales. The other templates will not use it, but it doesn't matter. Same goes for the dayOfWeek.

This way you automatically get the correct date output when you change the site-language too. Imagine a multilingual site, where you need English and say, Spanish translations. That's because the _t method will grab the correct template for the current language.

For the highest flexibility, you could allow the user to override some (or all) templates in the _config.php file.
There you could have something like:

$customTemplates = array(
    'diffMonthSameYear' => '%{sWeekDayShort}. %{sDayNum}. %{sMonShort}. - %{eWeekDayShort}. %{eDayNum}. %{eMonShort}., %{eYearFull}'
);

In the method that's responsible for the date-formatting, you would simply check isset($customTemplates['diffMonthSameYear']) to see if there's a custom template. Otherwise you'd use the default one coming from the lang file.

Go to Top