Hello Markus,
On Tuesday, November 6, 2007, 4:20:53 PM, you wrote:
MK> On Dienstag, 6. November 2007, cnit wrote:
>> > The other issue that I'm having is {{#ask}} parser function - not
>> > having it stops almost all of my development. It's probably the most
>> > anticipated feature right now. Do you have any timeline or at least
>> > defined approach to it?
[extra stuff edited out]
>> I am myself missing parser function badly, but I guess that
>> complaining too often won't speed up the development, rather bore the
>> developers..
MK> Well, you can always add some further pressure, but our development activity
MK> still is subject to various constraints that are outside our control (jobs,
MK> lives, ...) ;-)
MK> But maybe, since we are over it, we can start some design discussions about
MK> {{#ask...}}. In particular, parser functions have a slightly different style
MK> of parameters than parser hooks (<ask>). Our current <ask> has three parts:
MK> (1) the query conditions,
MK> (2) multiple print statements,
MK> (3) a variable set of parameters.
MK> Currently (1) and (2) can be mixed, although the position of print
statements
MK> relative to the query conditions has no effect. Moving to a parser function
MK> seems to be a good opportunity to revise some of this design, e.g. by simply
MK> making the print statements a separate parameter. In {{#ask..}}, everything
MK> must be passed as a parameter anyway, so separating (1) and (2) is no
MK> complication. How should an example query look like? Her is a suggested
MK> example transformation:
MK> <ask format="table" limit="12">
MK> [[Category:Person]] [[lives in::Europe]]
MK> [[lives in::*]]
MK> [[birthday::*|day of birth]]
MK> [[height::*m²|size]]
MK> </ask>
MK> becomes
MK> {{#ask|
MK> format=table|
MK> limit = 12|
MK> ?lives in|
MK> ?birthday = day of birth|
MK> ?height#m² = size|
MK> [[Category:Person]] [[lives in::Europe]]
MK> }}
MK> Basic points:
MK> * The query is always the last parameter.
MK> * No | appear unless they are used as separators between parameters.
MK> * Printouts start with "?"
MK> * All the known printout modifications somehow work, but in different
syntax.
MK> * We implicitly block "=" in property names (should we care?)
MK> Some of this syntax is not essential, but one must be careful not to collide
MK> with MediaWiki syntax. <ask> would of course continue to work in any case,
MK> but {{#ask}} would become the suggested method in the future.
MK> I guess the main point of discussion would be the printout-parameters. Many
MK> variations are possible, and comments are welcome.
On Monday, November 12, 2007, 9:31:03 PM, Jim Wilson wrote:
JW> Although I am in favor of {{#ask:}} at the earliest possible
JW> conveneince, after a cursory look through the code, I'm fairly certain
JW> this extension will fail to operate as expected.
JW> The first reason is that <ask>, which is an extension tag, will always
JW> return fully qualified HTML. The output of a parser function is
JW> expected to be wikitext, which will be further processed. The result
JW> is that if the output of the {{#ask:}} call contains any links,
JW> they'll be HTML links (like <a
JW> href="something">something</a>), not
JW> wiki text (like [[something]]). When the Parser reads these HTML tags
JW> during subsequent processing, it'll convert the '<' and '>' symbols to
JW> their entity equivalents '<' and '>' so in the browser you
JW> actually see '<a href="...">whatever</a>', not a nice link.
JW> The second reason is that one of the huge benefits of having an
JW> {{#ask:}} parser function is nesting. The idea that you could
JW> {{#ask:something={{#ask:something else}}}}. I'm not sure if SMW
JW> supports nested <ask> tags, but if not, this would also be a failure
JW> mode of the aforementioned extension.
JW> Again, I would like nothing more from SMW than an {{#ask:}} template -
JW> which would be a __HUGE__ improvement for advanced use cases, but I
JW> don't think that this extension is the answer everyone hopes it is.
JW> -- Jim R. Wilson (jimbojw)
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_"
"suffix="
Used with all formats to add text after everything else (in the
same way that "intro" adds text before everything else).
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.
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).
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>
{{#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=.|
}}
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.
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
...
|}
--
Peter Clements
-------------------------------------------------------------------------
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
