Sub parsers. In what kind of case does this kind of thing happen for you?
When one thing is being parsed, there is one parser doing that task. I
don't know of many cases where multiple parsers exist (unless an
extension is doing something screwy).
Have you tried making use of the ParserOutput? That seams like a to the
point thing, there should only be one of those for a parse.
~Daniel Friesen(Dantman, Nadir-Seen-Fire) of:
-The Nadir-Point Group (http://nadir-point.com)
--It's Wiki-Tools subgroup (http://wiki-tools.com)
--The ElectronicMe project (http://electronic-me.org)
--Games-G.P.S. (http://ggps.org)
-And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
--Animepedia (http://anime.wikia.com)
--Narutopedia (http://naruto.wikia.com)
Markus Krötzsch wrote:
Hi Daniel,
it's always refreshing to get some thorough code critique from you in the
morning -- thanks for caring! I have added you to our contributors' list, and
I would much appreciate your ideas on some further hacks that I am well aware
of, see below.
Anyone want to explain to me why the ParserBeforeStrip hook is being
used to register parser functions?
In defence of my code: it works. Up to the introductions of
ParserFirstCallInit it was also one of the few hooks that got reliably (at
least in my experience) called before any parser function would be needed.
That is a poor place for it, as well as unreliable. Which I can see by
how the function being called is a major hack relying on the first call
returning the callback name when already set..
Well, I have seen worse hacks (only part of which were in my code, but see the
remarks below on a major problem I still see there). But point taken for this
issue too.
Since I took the liberty of fixing up Semantic Forms, please see it as a
reference on how to correctly add Parser Functions to the parser:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SemanticForms/in
cludes/SF_ParserFunctions.php?view=markup
Great, I added similar code to SMW now.
To stay with this topic, I feel that the whole parser hooking business is
bound to be one large hack. As a parser extension that stores data, you need
to hook to several places in MW, hoping that they are somehow called in the
expected order and that nobody overwrites your data in between hooks. We have
to store the parsed data somewhere, and this place needs to be globally
accessible since the parser offers no local storage to us (none that would
not be cloned with unrelated subparsers anyway). But parsing is not global
and happens in many parsers, or in many, possibly nested, runs of one parser.
The current code has evolved to prevent many problems that this creates, but
it lacks a unified approach towards handling this situation.
Many things can still go wrong. There is no way of finding out whether we run
in the main parsing method of a wiki page text, or if we are just called on
some page footer or sub-parsing action triggered by some extension. Jobs and
extensions cross-fire with their own parsing calls, often using different
Title objects.
Do you have any insights on how to improve the runtime data management in SMW
so that we can collect data belonging to one article in multiple hooks, not
have it overwritten by other sub-hooks, and still do not get memory leaks on
very long runs? We cannot keep all data indefinitely just because we are
unsure whether we are still in a sub-parser and need the data later on. But
if we only store the *current* data, we need to find out what title actually
is currently parsed with the goal of storing or updating its data in the DB.
Best regards,
Markus
------------------------------------------------------------------------
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
------------------------------------------------------------------------
_______________________________________________
Semediawiki-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Semediawiki-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
