click-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <>
Subject Re: Click web architecture questions - services, transactions, etc.
Date Tue, 27 Apr 2010 13:41:36 GMT
With regard to Spring and stateful pages the SpringClickServlet option
3. "Click instantiated Pages with injected Spring beans and/or

This option could be modified to set the Spring Beans when Page
instance is activated to better support stateful pages:

regards Malcolm Edgar

On Tue, Apr 27, 2010 at 10:48 PM, Bob Schellink <> wrote:
> Hi Georgi,
> On 27/04/2010 18:53, gdenchev wrote:
>> Still, I am unsure how to solve some high level architectural questions with
>> regards to Click and its lifecycle.
>> I am going to ask here hoping that someone has been that road before.
>> (Please note that I am a long time Struts1 user with decent knowledge of
>> Spring)
>> So, here goes:
>> 1. Service layer (connected somehow to 2) - it it clearly a good practice to
>> isolate business logic from view/controller logic. I am thinking Spring
>> beans here, and we fortunately we have the means of integrating Spring and
>> Click using custom resolvers in Click Extras. The resolver (currently)
>> resolves Click pages as Spring non-singleton (prototype) beans and all other
>> components as Spring singleton beans (needs tweaking to extract metadata
>> from Spring configuration).
>> Now, the question: I suppose this is OK with Click stateless pages, but will
>> it behave nicely with stateful pages. I would love to hear some opinions
>> from the people with extensive Click knowledge.
> Stateful pages are stored in the HttpSession so there could be issues if the services
are referenced
> direclty from the Page. For example if the session is serialized to disk the services
are serialized
> as well. This might be acceptable but I assume it is not. There are two possible alternatives:
> mark the services as transient so they are not serialized to disk or 2) lookup the services
from the
> ApplicationContext instead.
> I believe 1) doesn't currently work across server restarts if the session is
> serialized/deserialized, as the service references are not re-injected by Spring. I'd
be interested
> to know if Spring has a way of dealing with this issue.
> The ApplicationContext on the other hand is always re-injected by the SpringClickServlet
and will be
> available after a server restart. If you look at the Click examples you'll notice this
pattern  used
> for stateful pages:
>> 2. Transaction management (connected somehow to 1) - we have some common
>> logic dealing with ORM/database transaction exception handling and want to
>> employ declarative (or at least common for the majority of pages)
>> transaction management. I have read numerous materials on the topic and
>> currently think that JBoss Seam has a good approach with its JSF
>> integration. Essentially Seam opens two transactions per request (if needed)
>> - one read/write transaction for the part before response rendering, and one
>> read-only transaction for the response rendering phase (
>> (
>> )
>> Now the question: Has someone considered using this declarative approach
>> with Click?
> We use Apache Cayenne which doesn't suffer from the Lazy load exception so I haven't
given too much
> thought to this problem lately :). It is an interesting topic however.
> It should be possible to implement two phased transactions in a SpringClickServlet subclass
> customizing the Click lifecycle method: #processPage. The method is fairly straightforward
if you
> need to customize it:
> The upcoming 2.2.0 release has a PageInterceptor which could make such an implementation
> I'd be interested to know your findings.
> Kind regards
> Bob

View raw message