https://bugzilla.wikimedia.org/show_bug.cgi?id=59788

--- Comment #8 from Daniel Kinzler <daniel.kinz...@wikimedia.de> ---
(In reply to comment #7)
> It seems to me that calling prepareContentForEdit() in an editing hook makes
> complete sense.

Having an object that represents an edit in progress makes sense, yes. It could
have the old Content and Revision, the new Content, and perhaps the new Content
with PST applied. But it should be a wrapper object though that generates and
remembers parsed versions on demand, not up front. It should also have a well
defined interface, not just glued together public members. 

Much could however be already achieved by re-using and passing Content objects.

> ParserCache works on the current version of an article, which isn't going to
> help much when you don't have an article yet and you haven't yet saved the
> text.

True. A transient object representing the edit at hand makes more sense.

> > * make getParserOutput cache the last result it returned, and return it 
> > again
> > if the parameters are the same.
> 
> That doesn't help when not everything uses the same Content object. Or a
> Content object at all.

Everything handling content should use Content objects. Otherwise, how can you
handle content without knowing what it is?

And yes, ideally, it would always be the same Content object. There really is
no good reason to re-create instances. The Content object should be created
when loading from the DB, or when handling a post request - once. 

Trying to avoid re-creation of Content objects would be a good strategy to find
and eliminate redundant processing, and would allow for local caching e.g. of
the ParserOutput. Perhaps this would be the best approach to address the
performance issues described in bug 57026.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to