From: Daniel W. <Dan...@we...> - 2011-09-22 03:59:12
|
Hi, I am just programming some changes to one of my SMW result formats, and was wondering about some functionality being broken. I figured out this is due to my update to SMW 1.6.2 and it seems like SMWResultPrinter::$mInline is always false for inline queries! I don't know where the object is created and the $inline parameter is given to the constructor, but the but must be there since there isn't anything wrong with the constructor itself and it worked fine in SMW 1.6.1 Can anyone confirm this perhaps or even knows where the bug lays? Daniel |
From: Daniel W. <Dan...@we...> - 2011-09-22 15:37:38
|
I have found the bug now doing some stack trace: It's in SMWParamFormat::doManipulation() where SMWQueryProcessor::getResultPrinter() is called, but with only one parameter, while the second parameter is defining the context e.g. whether the query is coming from an special page. Default is special page, so the context isn't set to inline for the result printing! Daniel Daniel Werner wrote: > Hi, > > I am just programming some changes to one of my SMW result formats, and > was wondering about some functionality being broken. I figured out this > is due to my update to SMW 1.6.2 and it seems like > SMWResultPrinter::$mInline is always false for inline queries! > > I don't know where the object is created and the $inline parameter is > given to the constructor, but the but must be there since there isn't > anything wrong with the constructor itself and it worked fine in SMW 1.6.1 > > Can anyone confirm this perhaps or even knows where the bug lays? > > Daniel |
From: Jeroen De D. <jer...@gm...> - 2011-09-22 23:20:05
|
Hey, > It's in SMWParamFormat::doManipulation() where SMWQueryProcessor::getResultPrinter() is called, but with only one parameter, while the second parameter is defining the context e.g. whether the query is coming from an special page. Default is special page, so the context isn't set to inline for the result printing! This seems odd to me. Sure, the argument might not be passed here, but then again, the query printer created here is only used to get the list of parameters it supports and is then discarded. Later on a new query printer is constructed for printing the actual output, which should get the relevant argument as it did before. Are you using $mInline in getParameters or any method called by it? If so, where and why? Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- |
From: Daniel W. <Dan...@we...> - 2011-09-22 23:48:33
|
Yeah, I am using it in getParameters() because within the context of semantic search special page I cant use Parser::preprocessToDom() to parse some of my config parameters. In this case I use some fallback value for the special page. Otherwise, I think I had to use Parser::parse() and I am not fully aware of the consequences really. Wouldn't even know which parameters I should supply. So right now I am using isset( $wgParser->mOptions ) instead of mInline to check whether I am in an inline context or not. I alreaedy noticed that mInline is working in handleParameters(), where I have to use it again to define for parameter 'name' that in non-inline context empty string '' is equally to null/unset while in inline context '' would be a valid value for the 'name'. (name='' or anything else for 'name' would create an non-visible output which would be veeery useless on the special page. Normally 'name' would not be set by the user if a "visible" output is required). Daniel Jeroen De Dauw wrote: > Hey, > > > It's in SMWParamFormat::doManipulation() where > > SMWQueryProcessor::getResultPrinter() is called, but with only one > > parameter, while the second parameter is defining the context e.g. > > whether the query is coming from an special page. Default is special > > page, so the context isn't set to inline for the result printing! > > This seems odd to me. Sure, the argument might not be passed here, but > then again, the query printer created here is only used to get the list > of parameters it supports and is then discarded. Later on a new query > printer is constructed for printing the actual output, which should get > the relevant argument as it did before. Are you using $mInline in > getParameters or any method called by it? If so, where and why? > > Cheers > > -- > Jeroen De Dauw > http://www.bn2vs.com > Don't panic. Don't be evil. > -- |
From: Jeroen De D. <jer...@gm...> - 2011-09-23 07:30:59
|
Hey, > Otherwise, I think I had to use Parser::parse() and I am not fully aware of the consequences really. Wouldn't even know which parameters I should supply. I'm not sure, but I think you should use recursiveTagParse here. Might be worth asking about on wikitech. > I alreaedy noticed that mInline is working in handleParameters(), where I have to use it again to define for parameter 'name' that in non-inline context empty string '' is equally to null/unset while in inline context '' would be a valid value for the 'name'. Right. You can do it just like that, as you then also take care of people actually providing an empty string. If you need to distinguish between it having been set by the user or being defaulted, you can set the default to false, which in case of string params is done by $param->setDefault( false, false ); where the first argument is the default value, and the second one indicates that the default value should not be handled like user values, ie not converted to a string. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- |
From: Daniel W. <Dan...@we...> - 2011-09-23 18:26:38
|
> > Otherwise, I think I had to use Parser::parse() and I am not fully > > aware of the consequences really. Wouldn't even know which parameters I > > should supply. > > I'm not sure, but I think you should use recursiveTagParse here. Might > be worth asking about on wikitech. Sure, normally you would use that instead of Parser::parse(), but if I can't use Parser::preprocessToDom() I also can't start ParserParser::recursiveTagParse(), both require a running Parser::parse() first. So I would only run the parser to use Parser::preprocessToDom() on my configuration value. Then I would use some hook where I can actually run Parser::preprocessToDom() Too much work and unstable for only making this work on the special page as it would look in inline mode. Daniel |