click-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gdenchev <>
Subject Click web architecture questions - services, transactions, etc.
Date Tue, 27 Apr 2010 08:53:38 GMT

Hello there,

I have been looking for a simple and extensible framework to use at work in
the last months.
I really like the simplicity of Click without compromises on flexibility.

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

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.

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? What about using this in Spring context with Spring declarative
transaction mamagement if we want to isolate our service layer as Spring
beans (see point 1)?
I am now fairly familiar with the Click lifecycle and maybe will try to
implement such transaction handling, but any pointers from seasoned Click
veterans will be of great help :)

Quite a long post, but these questions are important to me and currently are
stopping Click adoption in my company. Will be glad to hear any opinions on
this approach and possible alternatives. I hope that this will become a
useful conversation and may lead to some more useful Click examples.

Thanks in advance,
Georgi Denchev
View this message in context:
Sent from the click-user mailing list archive at

View raw message