Thinking out loud: Might I recommend that we encourage plugin
developers NOT to assume the presence of an HTTP request in 3.0?
It's going to be much cleaner simply to grab whatever parameters
Stripes binds to the ActionBean via their accessors (they will
correctly typed, among other things). E.g., if Stripes binds the
"page" request parameter to an ActionBean's property of type
WikiPage, why not just use getPage() to get it, rather than go
through trouble of getting the request from the context, calling
getParameter(), looking for nulls and misspellings etc...? So much
could go wrong, and Stripes takes care of this for you. So, in 3.0
a developer commandment might be:
It's already the norm - check out the javadocs. For example,
embedders would not see a HttpServletRequest in there. We have a
getHttpParameter() which checks for HTTP parameters safely.
The point why it exists is that certain plugins (like WikiForms) can
this way communicate with each other across invocations.
Aside: one of the things that pleases me the most about Stripes is
that its parameter-binding glue allows us to decouple the request
from the WikiContext. Likewise, the Resolution and related
UrlBuilder classes decouple it from the response.
Ah, but Stripes parameter binding is static. You can't add new
parameters at runtime without resorting to reading the request.
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.
I do not completely understand what you mean here, but I do not
think that WikiContext should be serializable. Today, it contains
references to too several things that have time-dependent states
(HttpServletRequests go out of scope; HttpSessions expire, etc.).
In the future, it would be extremely difficult to make WikiContexts/
ActionBeans serializable because that would mean all of their
properties would have to be serializable too. Not too hard with a
concrete class, but probably impossible with an interface, which is
what ActionBean is... would impede flexibility way too much.
Well, if you do want to serialize the state of the request across
workflows, then you might need to do that. We could add custom
serialization/deserialization code, which could go and create a
synthetic WikiContext when deserialized. What it would mean though
is global variables (i.e. singletons, like WikiEngine) which could be
accessed without knowledge of the context itself. So when
WikiContext is deserialized, it'll go and hydrate itself using
WikiEngine.getInstance(), etc. You will lose some information, but
that probably does not matter in the contexts that we will be using
it for (like workflows).
/Janne
