Yes, either the <% require %> tag or just plain html includes. The require tag is possibly the better choice since it prevents duplicates.
From studying the SSViewer class, I was able to figure out how this tag works:
The first part is the keyword "require", followed by the method to call with arguments in braces.
<% require css(path/to/my/file.css) %>
Will call Requirements::css('path/to/my/file.css');
I hacked the Calendar classes to output european-formatted dates. Not in a generic/reusable way though... that would require quite an amount of refactoring i guess.
I set the locale using setlocale. Then I changed the methods of the Calendar class to use strftime instead of date. Example:
@ banal - Glad you got it working. The part I'm struggling with is giving the user the ability to choose which format characters to plug into the date() function. For instance, some users may want "October" in lieu of "Oct." That only really matters in the getDateString() method that returns a magically rendered date span in its template function $_Dates. So I may just make that US format only for now, or limit the options for European. Ultimately, date display should be left to the template, so I don't mind empowering users to handle it as they wish using $StartDate.Format() and $EndDate.Format().
Yes, putting this stuff into templates makes sense. I'd keep the "magic" stuff to a minimum and rather provide start- and end-dates or other information the user can then mix freely in his templates. If he wishes another formatting, overriding the base class and adding custom controls (public methods) should do the trick.
Be sure to use strftime instead of date, since it is "locale-aware".
I'll check out if I can make the highlighting work..
Thanks for the strftime idea. Did not know date() wasn't locale aware.
Anxious to see what you come up with, though. It would be a great feature.
That's precisely the problem. All of the recurring events are injected on the PHP side, not in MySQL. I tried very hard to come up with a query that would work, but to no avail, it has to be done in the controller. That's why everything has to get routed through the Events() function.
One quick way to do it would be $this->UpcomingEvents(999). But that wouldn't get anything before today.
I'll have to revisit that Events function. It's pretty flexible. Should be able to throw it a start and end date (sfDate objects) and have it do its thing.