incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <Janne.Jalka...@ecyrd.com>
Subject Re: Shed light on how PageManager saves pages?
Date Wed, 25 Jun 2008 05:54:56 GMT
> 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

Mime
View raw message