On 28/04/2010 23:15, gdenchev wrote: > > Thank you both for your fast responces, much appreciated! > > Apparently I have missed the Spring integration with stateful pages example, > thanks for pointing that out. > It seems that we will use the 3rd approach to Spring integration as > described in the documentation.
I'm going to check in a fix shortly to make option 3 "bean injection" work for stateful pages. Currently one can only "pull" the beans from the ApplicationContext. > Regarding the transactions, I have started implementing the two-phased > transaction approach, but ran into the following problem: > I need to copy and modify (add logic) the SpringClickServlet.processPage > method. The method contains calls to protected static methods like > ActionEventDispatcher.getThreadLocalDispatcher(). In my experience this > makes extensions quite impossible. The same holds true for the ClickClick > extension project (hosted on Google code). Currently I will have to modify > the Click code itself to perform the extension. > Is this by design? Do you plan on making these static methods public or > replacing them with non-static methods alltogether? The ActionEventDispatcher is bound to a ThreadLocal, which is why it has the static accessor. We could make it public I suppose to in order to make extending ClickServlet easier. In a future release we want to include better Ajax integration which could affect the ActionEventDispatcher and #processPage code. Perhaps some of the code could move into a service, making it easier to extend the default behavior. Have you looked at the upcoming PageInterceptor? It seems to have the hooks you'll need for transaction code: preCreate(Class pageClass) postCreate(Page) preResponse(Page) postDestroy(Page) This would also allow you to conditionally include/exclude pages (by checking existence of certain interfaces?) from being involved in the transaction. 2.2.0-RC1 is fairly close to release. Kind regards Bob
