I think that's a great format for the {{ask}} parser function - it nicely
separates data from presentation; which are somewhat mixed together in
current inline queries.
Also, this is unrelated, but I discovered yesterday that inline queries in
SMW 1.0 can handle redirected pages (pages for which a property links to a
page that redirects to them now show up in query results), which is a great
feature. Thanks!
-Yaron
On Nov 6, 2007 11:20 AM, Markus Krötzsch <[EMAIL PROTECTED]> wrote:
> 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?
> >
> > I guess that "RC" thing means - "The development of major features is
> > temporarily frozen. Only small bugfixes are accepted". That approach
> > is used to make the code more stable.
>
> No, not quite. Two more features are scheduled for SMW1.0 final: one (as
> you
> know) is {{#ask}}, and the other is the listing of subproperties on
> property
> pages. We know that traditionally one would do RCs together with a feature
> freeze, but in a wiki one can certainly have optional features released
> also
> if they are less well-tested.
>
> The reasons why we have started releasing RCs are:
>
> * Some people started asking us whether the project was still alive ;-)
> * The developers of the Halo extension asked for an early release, so that
> they could release some code compatible with a fixed version of SMW.
> * More testing cannot hurt.
>
> The RC-process does not slow down our work on the aforementioned features
> --
> it would have been slow anyway.
>
> >
> > I am myself missing parser function badly, but I guess that
> > complaining too often won't speed up the development, rather bore the
> > developers..
>
> Well, you can always add some further pressure, but our development
> activity
> still is subject to various constraints that are outside our control
> (jobs,
> lives, ...) ;-)
>
> But maybe, since we are over it, we can start some design discussions
> about
> {{#ask...}}. In particular, parser functions have a slightly different
> style
> of parameters than parser hooks (<ask>). Our current <ask> has three
> parts:
>
> (1) the query conditions,
> (2) multiple print statements,
> (3) a variable set of parameters.
>
> Currently (1) and (2) can be mixed, although the position of print
> statements
> relative to the query conditions has no effect. Moving to a parser
> function
> seems to be a good opportunity to revise some of this design, e.g. by
> simply
> making the print statements a separate parameter. In {{#ask..}},
> everything
> must be passed as a parameter anyway, so separating (1) and (2) is no
> complication. How should an example query look like? Her is a suggested
> example transformation:
>
> <ask format="table" limit="12">
> [[Category:Person]] [[lives in::Europe]]
> [[lives in::*]]
> [[birthday::*|day of birth]]
> [[height::*m²|size]]
> </ask>
>
> becomes
>
> {{#ask|
> format=table|
> limit = 12|
> ?lives in|
> ?birthday = day of birth|
> ?height#m² = size|
> [[Category:Person]] [[lives in::Europe]]
> }}
>
> Basic points:
> * The query is always the last parameter.
> * No | appear unless they are used as separators between parameters.
> * Printouts start with "?"
> * All the known printout modifications somehow work, but in different
> syntax.
> * We implicitly block "=" in property names (should we care?)
>
> Some of this syntax is not essential, but one must be careful not to
> collide
> with MediaWiki syntax. <ask> would of course continue to work in any case,
> but {{#ask}} would become the suggested method in the future.
>
> I guess the main point of discussion would be the printout-parameters.
> Many
> variations are possible, and comments are welcome.
>
> >
> > I am investigating my own upgrade, too. My temporarily solution for
> > dynanical queries will be small patch I plan to make unpublished -
> > just simply %FUNCTION_NAME% inside query param will be replaced
> > with result of the call to according PHP function, instead of template.
> > Should be easy to implement (with some security restrictions, of course
> > - though my wiki is not public).
> >
> > When the function will be available, I'll switch to these.
>
> Yes, that would be a very versatile mechanism indeed.
>
> Cheers,
>
> Markus
>
> > Dmitriy
> >
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems? Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Semediawiki-devel mailing list
> > Semediawiki-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>
>
> --
> 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
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
