My question is, is there anything special about the WikiContext
that we retrieve, which is passed to textToHTML() and
doPostSaveFiltering()? Could we create a synthetic one instead? In
other words, I am proposing that in PreSaveTask we stash the
WikiPage name as a string, then pick it up in SaveTask and use it
to manufacture a new, fake WikiContext with the correct WikiPage.
Yup, we've got a problem. Most things in the WikiContext are such
that they do not survive serialization - WikiEngine,
HttpServletRequest, even WikiPage (due to interactions with the
CachingManager).
It's a good question whether they even do survive leaving the
WikiSession and being executed in somebody else's context (the
HttpServletRequest comes to mind). Now, since SavePageTask.execute()
invokes the parser, that means that user plugins are also invoked,
and if you've got someone relying on HttpServletRequest parameters at
the time of save parsing - well, boom for them. (Not that I would see
that anyone would do that.)
Conversely, if the WikiContext used by textToHTML() and
doPostSaveFiltering() *has to be* the same WikiContext (and not
created synthetically), then we've got to keep stashing it as a
workflow attribute, and thus (here's the punchline)... we will
never to be able to persist workflows.
Yes.
The reason we call textToHTML() is to make sure the access rules and
metadata are correct after save. This is needed because of the
CachingProvider, and is one of the reasons why our metadata system is
so crappy and kludgy and I can't wait to start fixing it in 3.0...
Looking at the issues involved, I think it probably makes more sense
to stuff this to 3.0 and see if we can clarify the role of the
WikiContext a bit more. If WikiContext is going to be a Stripes
ActionBeanContext in the future, we've got to make sure that is
serializable too, of which I am not too sure about.
/Janne
