Oh, interesting - that's not what I expected "sep" would do, though I've never used it myself so I wouldn't know. In any case, a parameter to separate results definitely sounds useful - does anybody have any thoughts on what it should be named? "delimiter", maybe?

It's true about that linguistic confusion, though in my experience the phrase "multi-value properties" always refers to multiple-type properties (maybe that's a better name for them, actually). The other kind you can refer to as "multiple values for the same property", or "for the same field" if you're using templates.

-Yaron


On Thu, Feb 26, 2009 at 12:53 PM, Dave Loomer <dloomer@gmail.com> wrote:
The "sep" seems to be used when a result field refers to a property
that is explicitly defined as multi-valued.  The hardcoded comma is
used when a result refers to multiple pages, which in my case occurs
when the page corresponding to a given row has a single property
defined multiple times with different values. (e.g. [[MyProperty::Some
Value]] [[MyProperty::Some Other Value]], as opposed to
[[MyProperty::Some Value;Some Other Value]]).

By the way, that's a mouthful, and it brings me to the fact that I
really don't know what to properly call and distinguish these two
types of multi-valued properties.  Without knowing the lingo, it's
proven pretty difficult to use Google for the help I've tried to get
on their usage (although some recent posts on this list seem to have
cleared up what questions I've had).  What terms should I be using?


On Thu, Feb 26, 2009 at 11:23 AM, Dave Loomer <dloomer@gmail.com> wrote:
> I tried out the "sep" parameter and it seems to be used for something
> else -- I can't remember what at the top of my head.  But the
> separator I'm speaking of is definitely hardcoded into SMW_QP_List
> (and so I've hardcoded it into the calendar and timeline formats as
> well):
>
>                                        while ( ($text = $field->getNextText(SMW_OUTPUT_WIKI,
> $this->getLinker($first_col))) !== false ) {
>                                                if ($first_value) $first_value = false; else $wikitext .= ', ';
>                                                $wikitext .= $text;
>                                        }
>
>
> Again, I'm pretty sure "sep" still has some effect on SMW_QP_List in
> some cases, and I need to dig in again to remember what it was.
>
>
> On Thu, Feb 26, 2009 at 11:18 AM, Yaron Koren <yaron57@gmail.com> wrote:
>> 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.
>>
>> -Yaron
>>
>> On Thu, Feb 26, 2009 at 12:06 PM, Dave Loomer <dloomer@gmail.com> 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?
>>>
>>> Dave
>>>
>>>
>>> On Wed, Feb 25, 2009 at 10:24 AM, Yaron Koren <yaron57@gmail.com> 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 <dloomer@gmail.com> 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 <yaron57@gmail.com> 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 <dloomer@gmail.com>
>>> >> > 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
>>> >> >> http://semantic-mediawiki.org/wiki/Help:Calendar_format, 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:
>>> >> >>
>>> >> >>
>>> >> >> http://www.nabble.com/Use-templates-for-formatting-of-results-in-Calendar-and-Timeline--tp22150785p22150785.html
>>> >> >> Sent from the Semantic Mediawiki - User mailing list archive at
>>> >> >> Nabble.com.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> ------------------------------------------------------------------------------
>>> >> >> 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
>>> >> >> http://p.sf.net/sfu/XcvMzF8H
>>> >> >> _______________________________________________
>>> >> >> Semediawiki-user mailing list
>>> >> >> Semediawiki-user@lists.sourceforge.net
>>> >> >> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
>>> >> >
>>> >> >
>>> >
>>> >
>>
>>
>