click-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gdenchev <>
Subject Re: Click web architecture questions - services, transactions, etc.
Date Thu, 29 Apr 2010 10:21:09 GMT

Bob Schellink wrote:
> 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.

Oh, I see now that the only method commonly invoked for stateful and
stateless Pages is SpringClickServlet.activatePageInstance and it only
pushes the ApplicationContext to the page.
The fix you mentioned will be highly appreciated, thanks in advance. Until
then we will be "pulling" service beans from the context manually.

Bob Schellink wrote:
>> 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.

I examined the PageInterceptor capabilities, and indeed it has everything
necessary for implementing the two-phase transaction approach. Currently I
am modifying the ClickServlet.onProcess method and can easily migrate the
code to using the interceptor after the release of Click 2.2.0.

Bob Schellink wrote:
> 2.2.0-RC1 is fairly close to release.
> Kind regards
> Bob

I will be surely waiting for this release :)
Thanks again for all the pointers.
Will try to post the code for the two-phase approach when implemented and

Best regards,
View this message in context:
Sent from the click-user mailing list archive at

View raw message