From: Sergey C. <sem...@an...> - 2007-11-06 18:11:52
|
Markus, thank you for the follow-up! It's great to know that {{#ask}} is scheduled for 1.0 release! I'm happy to participate in architectural discussion. Here're some thoughts on the subject: 1. it seems to be to restricting on query language to remove pipes and equal signs from it - who knows, maybe you'll want to have '|' character= s in OR-like statements or '=3D' in filtering statements. 2. I'm not sure if it makes a lot of sense to change the format of query language from old version to new one I can propose, if not very elegant, but a solution - make a query to be a last parameter and let's have a name for it, e.g. 'query' - all parameters after the one that start with ~/^query\s+=3D/ will get joined to it using a pipe. In your example: <ask format=3D"table" limit=3D"12"> [[Category:Person]] [[lives in::Europe]] [[lives in::*]] [[birthday::*|day of birth]] [[height::*m=B2|size]] </ask> will get converted to: {{#ask:format=3Dtable|limit=3D12|query=3D [[Category:Person]] [[lives in::Europe]] [[lives in::*]] [[birthday::*|day of birth]] [[height::*m=B2|size]] }} Here's the pseudo-code for this: function askParserFunc (&$parser) { $params =3D func_get_args(); array_shift($params); # first one is parser - we don't need it $query =3D ''; $queryfound =3D false; foreach ($params as $param) { if (!$queryfound) { if (preg_match('/^query\s+=3D/', $param)) { $query =3D preg_replace('/^query\s+=3D/', '', $param); // all params after this one will get appended to $query $queryfound =3D true; continue; } ... process all the rest of params ... } else { $query.=3D'|'.$param; } } ... do actual inline query work ... } I didn't test the code, but I used func_get_args approach and it worked for me. This can be used if you keep current syntax or introduce new one. What do you think of this approach. Sergey On Nov 6, 2007 11:20 AM, Markus Kr=F6tzsch <ma...@ai...> wrot= e: > 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 featur= e > 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 tha= t > 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=3D"table" limit=3D"12"> > [[Category:Person]] [[lives in::Europe]] > [[lives in::*]] > [[birthday::*|day of birth]] > [[height::*m=B2|size]] > </ask> > > becomes > > {{#ask| > format=3Dtable| > limit =3D 12| > ?lives in| > ?birthday =3D day of birth| > ?height#m=B2 =3D 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 "=3D" 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 > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > -- > Markus Kr=F6tzsch > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > ma...@ai... www http://korrekt.org > |