Hey,
Is there currently a way for extensions to register additional info they gather during the parsing process to the parser output? Right now Semantic MediaWiki is doing this by assigning to the non-defined field $mSMWData which causes notices when strict is on with PHP 5.4, so I am looking for a good way to fix this.
If there is no way to currently do this I propose this very simple addition: https://gerrit.wikimedia.org/r/#/c/28767/
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
On Fri, 19 Oct 2012 15:12:33 -0700, Jeroen De Dauw jeroendedauw@gmail.com wrote:
Hey,
Is there currently a way for extensions to register additional info they gather during the parsing process to the parser output? Right now Semantic MediaWiki is doing this by assigning to the non-defined field $mSMWData which causes notices when strict is on with PHP 5.4, so I am looking for a good way to fix this.
If there is no way to currently do this I propose this very simple addition: https://gerrit.wikimedia.org/r/#/c/28767/
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
Usually one uses setProperty and/or addOutputHook.
Hey,
Daniel, thanks for your suggestion.
Going on the little documentation, "Name/value pairs to be cached in the DB", it seems that everything added via setProperty goes into the parser cache. There is no point in this data going in there, so using setProperty does not seem ideal. Anything more suited already there?
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
On Sat, 20 Oct 2012 06:14:36 -0700, Jeroen De Dauw jeroendedauw@gmail.com wrote:
Hey,
Daniel, thanks for your suggestion.
Going on the little documentation, "Name/value pairs to be cached in the DB", it seems that everything added via setProperty goes into the parser cache. There is no point in this data going in there, so using setProperty does not seem ideal. Anything more suited already there?
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
Wait, I can understand wanting data that goes into the cached parser output but is not saved into page_props.
But are you saying that this SMW isn't actually used at all after parsing is finished, only during?
Hi Daniel, hi Jeroen, hi all,
On 20/10/12 16:47, Daniel Friesen wrote:
On Sat, 20 Oct 2012 06:14:36 -0700, Jeroen De Dauw jeroendedauw@gmail.com wrote:
Hey,
Daniel, thanks for your suggestion.
Going on the little documentation, "Name/value pairs to be cached in the DB", it seems that everything added via setProperty goes into the parser cache. There is no point in this data going in there, so using setProperty does not seem ideal. Anything more suited already there?
Cheers
...
Wait, I can understand wanting data that goes into the cached parser output but is not saved into page_props.
But are you saying that this SMW isn't actually used at all after parsing is finished, only during?
The data is used during and right after parsing, when the article is saved. The task here is to allow hooks to collect information during parsing and to process this information afterwards. The purpose of the change is to pass information sideways from one hook to the next. It would not be useful to store any of this information in the MW DB or in any cache.
Markus
On Sat, 20 Oct 2012 09:15:15 -0700, Markus Krötzsch markus@semantic-mediawiki.org wrote:
Hi Daniel, hi Jeroen, hi all,
On 20/10/12 16:47, Daniel Friesen wrote:
On Sat, 20 Oct 2012 06:14:36 -0700, Jeroen De Dauw jeroendedauw@gmail.com wrote:
Hey,
Daniel, thanks for your suggestion.
Going on the little documentation, "Name/value pairs to be cached in the DB", it seems that everything added via setProperty goes into the parser cache. There is no point in this data going in there, so using setProperty does not seem ideal. Anything more suited already there?
Cheers
...
Wait, I can understand wanting data that goes into the cached parser output but is not saved into page_props.
But are you saying that this SMW isn't actually used at all after parsing is finished, only during?
The data is used during and right after parsing, when the article is saved. The task here is to allow hooks to collect information during parsing and to process this information afterwards. The purpose of the change is to pass information sideways from one hook to the next. It would not be useful to store any of this information in the MW DB or in any cache.
Markus
Mind mentioning which hooks these are? Do they get a parser output explicitly or are they getting it from the parser?
P.S.: I have now seen that the discussion on gerrit is actually already a lot further than in this thread. Looks like we have a feasible conclusion there already. https://gerrit.wikimedia.org/r/28767
On 20/10/12 17:15, Markus Krötzsch wrote:
Hi Daniel, hi Jeroen, hi all,
On 20/10/12 16:47, Daniel Friesen wrote:
On Sat, 20 Oct 2012 06:14:36 -0700, Jeroen De Dauw jeroendedauw@gmail.com wrote:
Hey,
Daniel, thanks for your suggestion.
Going on the little documentation, "Name/value pairs to be cached in the DB", it seems that everything added via setProperty goes into the parser cache. There is no point in this data going in there, so using setProperty does not seem ideal. Anything more suited already there?
Cheers
...
Wait, I can understand wanting data that goes into the cached parser output but is not saved into page_props.
But are you saying that this SMW isn't actually used at all after parsing is finished, only during?
The data is used during and right after parsing, when the article is saved. The task here is to allow hooks to collect information during parsing and to process this information afterwards. The purpose of the change is to pass information sideways from one hook to the next. It would not be useful to store any of this information in the MW DB or in any cache.
Markus
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Do please still answer my question about hooks. I'm fine with adding unindexed properties into the parser output. But I'm getting a felling that what you're talking about for SMW needs something completely different.
On 20/10/12 18:15, Markus Krötzsch wrote:
The data is used during and right after parsing, when the article is saved. The task here is to allow hooks to collect information during parsing and to process this information afterwards. The purpose of the change is to pass information sideways from one hook to the next. It would not be useful to store any of this information in the MW DB or in any cache.
Markus
Then unset it at the point when you collect it, just before it is saved.
Also note that ParserOutput already stores much more than it strictly needs, so adding one more item won't harm.
Hey,
Then unset it at the point when you collect it, just before it is saved.
It'd be great if we could do that, since it's both simple and does not raise compat concerns. However, we are collecting it after it is saved as far as I can tell, in which case this is not going to work.
The properties are written into the parser cache in LinksUpdate right?
Also note that ParserOutput already stores much more than it strictly needs, so adding one more item won't harm.
This item can be big. Perhaps it's not that big of an issue, but still better to avoid it if we can.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
On 20/10/12 09:12, Jeroen De Dauw wrote:
Hey,
Is there currently a way for extensions to register additional info they gather during the parsing process to the parser output? Right now Semantic MediaWiki is doing this by assigning to the non-defined field $mSMWData which causes notices when strict is on with PHP 5.4, so I am looking for a good way to fix this.
That's the way a lot of extensions do it. Can you show the text of the E_STRICT notice? It seems to work for me:
$ /usr/local/php-master-nodebug/bin/php --version PHP 5.5.0-dev (cli) (built: Jul 31 2012 13:10:24) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
$ /usr/local/php-master-nodebug/bin/php -a Interactive shell
php > error_reporting(E_ALL|E_STRICT); php > class Foo {} php > $foo = new Foo; php > $foo->blah = 'blah';
No notice. Of course, this gives a notice:
php > $foo->bar;
Notice: Undefined property: Foo::$bar in php shell code on line 1
But that's what isset() is for.
-- Tim Starling
Hey Tim,
The notice is
Notice: Undefined property: ParserOutput::$mSMWData in /home/j/www/phase3/extensions/SemanticMediaWiki/includes/SMW_ParseData.php on line 170
Looking at this again I figure it might indeed not be set and that I accidentally fixed this while updating the code to use the modification I submitted to core. The notice is occurring when I run the Wikibase tests, which I only very recently started running when SMW is loaded (since content handler is in core), so it might be related to that. Will investigate tomorrow.
In any case, do you think it's fine for extensions to set such non-defined fields, or would it be better to go in the direction of the patch that's on gerrit? https://gerrit.wikimedia.org/r/#/c/28767/
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
On 22/10/12 11:26, Jeroen De Dauw wrote:
In any case, do you think it's fine for extensions to set such non-defined fields, or would it be better to go in the direction of the patch that's on gerrit? https://gerrit.wikimedia.org/r/#/c/28767/
I think it's fine for extensions to continue to set custom fields in ParserOutput.
At least one contributor to this thread seems to be confused about what setProperty() is for, and the docs were very vague, so I have proposed updated documentation here:
https://gerrit.wikimedia.org/r/#/c/28971/
Note that this pattern of setting custom variables in objects which are passed to hooks is widely used, it's not just a ParserOutput thing.
-- Tim Starling
wikitech-l@lists.wikimedia.org