Cool. That's great about the timeline format too - I believe the author of that format is Markus, and he's on this list too, :) but I can add your changes in as well.

For the separator, there already exists a "sep" parameter that does that - it's certainly implemented for lists, although it would be nice to have it implemented for the more complex formats as well.


On Thu, Feb 26, 2009 at 12:06 PM, Dave Loomer <> wrote:
Hi Yaron,

I'm happy to help out.  I actually found a small bug in my code for
when a result field contains multiple values -- I wasn't separating
them with a comma as is done in SMW_QP_List.  I've corrected that and
attached the new version.

I also put template functionality into SRF_Timeline and attached that
as well.  I realize you're not the author of this format, so let me
know if it might be best to contact him directly.  I'm also going to
want to add functionality to optionally specify a second template for
the "popup" that displays when you click an event on the timeline, as
well as a parameter to optionally go directly to the page of the
timeline event rather than display the popup when clicking the event
in the timeline.  I might be able to finish this soon, but I'll just
upload this version for now in case it takes me a while.

For both formats, as well as the List format (and possibly others?)
I'm also going to add a parameter to optionally specify a separator
other than a comma to use when a result field contains multiple
values.  If it's known that one of said values might itself contain a
comma, a comma separator becomes kind of useless especially if you're
going to want to use Semantic Forms' #arraymap to parse them back out
in your template code.  I think ultimately this property might belong
in the SMW_QueryPrinter base class if it's going to be used throughout
the various result formats, but I think I'm going to hold off from
touching the base class and just put it in the three subclasses I've
mentioned for the time being.  What do you think?


On Wed, Feb 25, 2009 at 10:24 AM, Yaron Koren <> wrote:
> Hi Dave,
> This looks great. I tested it out, and it seemed to work fine, other than
> the lack of handling for the "link" parameter, which you noted; I don't
> think that's a major problem, though. I checked your changes in, so they're
> now officially part of the Calendar format. Thanks for your contribution!
> And welcome to the wonderful world of PHP, MediaWiki and SMW programming. :)
> -Yaron
> On Tue, Feb 24, 2009 at 8:53 PM, Dave Loomer <> wrote:
>> Thanks Yaron.  This was a pretty good experience -- I used
>> SMW_QP_List.php as my guide, and had some troubles along the way due
>> to some differences between it and the current SRF_Calendar (listed
>> below), but I figured it out I think.  I also ended up re-using your
>> code for formatting date output based on whether the SMW version is
>> 1.4 or higher (another note on that below), so I broke that into its
>> own function.
>> Next I'll do the same for the Timeline format, and will also create a
>> third format like Google Calendar's "agenda" view which lists events
>> vertically, grouped by date.  That is, unless someone knows of an
>> output format just like this which already exists.
>> To list some of the challenges I encountered along the way, mostly to
>> call out areas of my changes that should receive attention if
>> reviewing the code:
>> - SRF_Calendar overrides getResult, and streamlines it considerably,
>> while SMW_QP_List just yields to the base class method.  The base
>> class method is where all of the parsing of the template text takes
>> place (calls to $wgParser->replaceVariables and
>> $wgParser->recursiveTagParse).  I found I couldn't just put the
>> template-parsing code in the overriden method, because it ended up
>> escaping some non-MediaWiki-compliant HTML such as anchor and input
>> tags.  Basically, as far as I can tell getResult needs to treat the
>> entire body of generated text as either HTML or Wiki Text, and not
>> both unless all the embedded HTML is MediaWiki-compliant (again, not
>> the case for SRF_Calendar).  So, I moved the calls to
>> $wgParser->replaceVariables and $wgParser->recursiveTagParse into the
>> displayCalendar method, calling them each time it encounters template
>> code, operating only on that chunk of code (of course, if a template
>> was not specified in the calling page/template, it just generates a
>> URL for the given result as it used to).
>> - Along with the above, I put a <span> around the generated template
>> text with a color specified when $color is defined.  I haven't been
>> able to test this to make sure it works properly.
>> - If the calendar format is specified with "link=none" it has no
>> effect.  I wasn't sure how best to do this.  I tried mimicking the way
>> it's done in SMW_QP_List (calling $this->getLinker instead of just
>> referencing $skin when specifying arguments for getShortText() and
>> getLongText()) but had issues.  The way it is is useful to me, though.
>> Also -- a note on the existing code for formatting date output.  I
>> kept it as-is, but in cases where SMW is not 1.4 or greater, that
>> branch of the logic references a variable $event_date which I don't
>> believe will be defined (both in the current and new SRF_Calendar
>> versions).  Maybe it should reference $object instead, but I decided
>> not to touch it.
>> On Sun, Feb 22, 2009 at 5:51 PM, Yaron Koren <> wrote:
>> > It's true that the Calendar format doesn't support the 'template'
>> > parameter,
>> > and it's also true that such support would be very useful. No need to
>> > create
>> > a separate Calendar format; if you were to add in handling of templates
>> > to
>> > the existing code, and send your new version to this list, I (or someone
>> > else) would be very happy to add that in to the official code. Such a
>> > project might be a good introduction to PHP (and MediaWiki and SMW)
>> > programming, since it seems like it would be pretty straightforward;
>> > mostly
>> > a matter of copying existing code from SMW and adding it in to the
>> > Calendar
>> > format.
>> >
>> > -Yaron
>> >
>> >
>> > On Sun, Feb 22, 2009 at 3:58 PM, David Loomer <> wrote:
>> >>
>> >> I'm having a hard time getting a handle of the options available in
>> >> using
>> >> the
>> >> Calendar and Timeline result formats for an inline query.  As far as I
>> >> can
>> >> tell, the Calendar format for example has a "limit" parameter option --
>> >> and
>> >> that's it.  That's all that seems documented at
>> >>, at least.
>> >>
>> >> What I'm getting at is: by default, the Calendar format shows each
>> >> result
>> >> simply as the name of the page (namespace included) corresponding to
>> >> the
>> >> given result for the text linking to the page.  I'd like to have more
>> >> control over this display, per the "|template=" option I have with
>> >> other
>> >> display formats (such as "ul", for instance).  However, when I insert
>> >> "|template=MyTemplate" nothing is changed, and the list of templates
>> >> used
>> >> shown during Edit mode does not list MyTemplate as one of the templates
>> >> used.
>> >>
>> >> At the very least I'd like the option of showing the text of the link
>> >> without the namespace, which in my particular case creates clutter, but
>> >> ideally I'd have much more than that, i.e., I would like to build my
>> >> own
>> >> test for display using properties on the page itself, using a template.
>> >>
>> >> Is this possible?  Or should I just learn PHP (not a stretch for me)
>> >> and
>> >> build my own custom Calendar format?
>> >> --
>> >> View this message in context:
>> >>
>> >>
>> >> Sent from the Semantic Mediawiki - User mailing list archive at
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Open Source Business Conference (OSBC), March 24-25, 2009, San
>> >> Francisco,
>> >> CA
>> >> -OSBC tackles the biggest issue in open source: Open Sourcing the
>> >> Enterprise
>> >> -Strategies to boost innovation and cut costs with open source
>> >> participation
>> >> -Receive a $600 discount off the registration fee with the source code:
>> >> SFAD
>> >>
>> >> _______________________________________________
>> >> Semediawiki-user mailing list
>> >>
>> >>
>> >
>> >