On Samstag, 17. November 2007, Peter Clements wrote: > Hello Markus, > <snip>
Hi Peter.
First of all: thanks for that discussion. I think parameter cleanup/extension
in a planned way is truly needed, and a public discussion is a good idea. All
of this should probably come with some mechanism for parameter
internationalisation and aliasing.
I have some comments below.
>
> As Jim notes, when used with {{#ask:}}, all of the Query Printers will
> need to use wiki formatting rather than HTML, but that should not be
> too difficult I would have thought.
>
> Since Markus is asking about updating the parameter passing
> conventions for use with queries (especially in relation to Query
> Printers), I thought I would step in with some suggestions that I have
> been harbouring for some time.
>
> Extra 'top level' parameters
> ============================
>
> "lastsep="
>
> Used with "format=list" to control the separator between the last
> pair of rows.
>
> Currently, if you use "sep=", the value you give is used between
> all rows (including the last pair).
>
> Example:
>
> format=list sep=",_" lastsep=",_or_"
Agreed.
>
> "suffix="
>
> Used with all formats to add text after everything else (in the
> same way that "intro" adds text before everything else).
Agreed, though this suggests to call "intro" "prefix" instead (needs an alias
to still allow "intro" for existing wikis).
>
> Field specific parameters
> =========================
>
> When a field has multiple values, they are always formatted with ", "
> as the separator for "format=list", "format=ul", and "format=ol", and
> always formatted with "<br>" as the separator for "format=table". This
> needs to be made more flexible too as I have wikis where some fields
> might actually have a dozen or more values and I'd really like to
> format them as a simple comma separated list. In fact you need to be
> able to format each field independantly of every other field.
Yes, I know of these limitations, and as you already found out, the new format
for printout-requests was also motivated by the idea of simplifying such
extensions.
>
> Currently, the only extra 'field specific' parameter is the alternate
> name that is displayed.
>
> The extra ones I believe would come in useful are:
>
> "prefix=" and "suffix="
>
> Specify text to appear before and after the values for a field.
>
> "format="
>
> Specify how the values of the field should be displayed.
>
> Choices of "list" (with the use of "sep=" and "lastsep=" options),
> "ul", "ol", or "template" (with use of "template=" option).
>
> "link="
>
> Specify whether values that refer to other pages should be
> displayed as links or not.
>
> Choices of "yes", or "no".
>
> "header="
>
> Specify whether or not the field name should be displayed (and if
> it is displayed: whether it should be displayed as a link)
>
> Choices of "link", "show", "hide".
>
> "template="
>
> Specify the template to use to display the values for the field.
> The template specified would be able to use any wiki formatting it
> likes (including creating an embedded table).
Basically all agreed, though I fear that even a very good syntax will render
these features mostly incomprehensible to normal users. But there is
obviously some minimal complexity inherent to the task we want to solve here.
One more that you did not add: "limit" (sometimes you just don't want more
than a few entries, and maybe [configurable] a link to more results).
>
> Example:
>
> <ask format="table" limit="12">
> [[Category:Person]] [[lives in::Europe]]
> [[lives in::*||header=hide]]
> [[birthday::*|day of birth]]
> [[height::*m²|size]]
> [[friends::*||format=template|template=FriendInfo]]
> [[interests::*||format=ul]
> [[other::*|Other|format=list|prefix="Some
> Text:"|lastsep=",_or_"|suffix=.]] </ask>
Actually I do not care much about this one. <ask> will probably die out soon
enough when {{#ask}} works as expected. So we can avoid further overloading
of MediaWiki link syntax.
>
> {{#ask:
> [[Category:Person]] [[lives in::Europe]]|
> format=table|
> limit=12|
> ?lives in=:header=hide|
> ?birthday=Day or birth|
> ?height=Size:unit=m²|
> ?friends=Friends:format=template:template=FriendInfo|
> ?interests=Interests:format=ul
> ?other=Other:format=list:prefix="Some Text:":lastsep=",_or_":suffix=.|
> }}
Units are currently appended via #, as in
?height#m² = Size|
Appending parameters via ":" seems feasible as a base syntax. However, I
consider supplying another parserfunction as syntactic sugar, e.g. like
?other=Other {{#ask-print:format=list|prefix=Some Text:|lastsep=,_or_|
suffix=.}}|
>
> The use of "template=" with "format=list", "format=ul", and "format=ol"
> =======================================================================
>
> Currently, if your wiki includes any pages that have an "=" sign in
> their title, and you then reference those pages using a relation from
> another page, or if the page itself is matched by a query, the page
> link does not display correctly when using "template=".
>
> This is caused by code like the following in
> SMWTemplateResultPrinter::getHTML
>
> $wikitext = '';
> $firstcol = true;
> foreach ($row as $field) {
> $wikitext .= "|";
> $first = true;
> while ( ($text = $field->getNextWikiText($this->getLinker($firstcol)))
> !== false ) { if ($first) {
> $first = false;
> } else {
> $wikitext .= ', ';
> }
> $wikitext .= $text;
> }
> $firstcol = false;
> }
> $parserinput .= '{{' . $this->m_template . str_replace('=','|',
> $wikitext) . '}}'; // encode '=' for use in templates (templates fail
> otherwise)
>
> Better code would be:
>
> $wikitext = '';
> $firstcol = true;
> $fieldnum = 1;
> foreach ($row as $field) {
> $wikitext .= "|" . $fieldnum . "=";
> $fieldnum += 1;
> $first = true;
> while ( ($text = $field->getNextWikiText($this->getLinker($firstcol)))
> !== false ) { if ($first) {
> $first = false;
> } else {
> $wikitext .= ', ';
> }
> $wikitext .= $text;
> }
> $firstcol = false;
> }
> $parserinput .= '{{' . $this->m_template . $wikitext . '}}';
>
> This follows Mediawiki's own guidelines for dealing with positional
> parameters that might have values with an "=" sign in them.
Good point. Will soon be implemented this way.
>
> CSS Styles and "format=table"
> =============================
>
> If you use "format=table", you have no control over the look of the
> resulting table (other than by editing SMW_custom.css which then
> applies to every query on the wiki).
>
> It would be nice if we could override SMW_custom.css for individual
> queries:
>
> {{#ask:
> $table="background-color:#ccffff; border-spacing:0pt; padding: 0pt;"|
> $th="background-color: #FFEEEE;"|
> $tr.odd="background-color:#ffccff;"|
> $tr.even="background-color:#ffffcc;"|
> $td="padding-left: 5pt; padding-right: 5pt"|
> ...
> }}
>
> Which would be expanded to:
>
> {| class="smwtable" id="querytable#" style="background-color:#ccffff;
> border-spacing:0pt; padding: 0pt;"
>
> |-
>
> ! style="background-color: #FFEEEE;" | Header
>
> |- style="background-color:#ffccff;"
> | style="padding-left: 5pt; padding-right: 5pt" | Odd Row
> |- style="background-color:#ffffcc;"
> | style="padding-left: 5pt; padding-right: 5pt" | Even Row
> |- style="background-color:#ffccff;"
> | style="padding-left: 5pt; padding-right: 5pt" | Odd Row
> |- style="background-color:#ffffcc;"
> | style="padding-left: 5pt; padding-right: 5pt" | Even Row
>
> ...
>
> |}
Another nice idea. Again this is much easier (saver) for {{#ask }}, since
MediaWiki then (hopefully) takes care of possible CSS-XSS attacks. Note that
the sorting script (which will, btw., soon be fixed to support non-alphabetic
columns again) needs to take the "striped" table layout into account, which
it currently doesn't.
My only fear is the increasing complexity of all that, but it seems that the
hacks that people already use to emulate these features are even worse
anyway :-/
Markus
--
Markus Krötzsch
Institut AIFB, Universät Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362 fax +49 (0)721 608 5998
[EMAIL PROTECTED] www http://korrekt.org
pgpsXhRQxhvdL.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
