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: 1) 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: http://www.avoka.com/click-examples/source-viewer.htm?filename=WEB-INF/classes/org/apache/click/examples/page/introduction/AdvancedTable.java > 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 ( > http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.2/doc/seam/Seam_Reference_Guide/Seam_and_ObjectRelational_Mapping-Seam_managed_transactions.html > (http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.2/doc/seam/Seam_Reference_Guide/Seam_and_ObjectRelational_Mapping-Seam_managed_transactions.html > ) > 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 by customizing the Click lifecycle method: #processPage. The method is fairly straightforward if you need to customize it: http://fisheye6.atlassian.com/browse/click/trunk/click/framework/src/org/apache/click/ClickServlet.java?r=HEAD The upcoming 2.2.0 release has a PageInterceptor which could make such an implementation simpler: http://fisheye6.atlassian.com/browse/click/trunk/click/framework/src/org/apache/click/PageInterceptor.java?r=HEAD I'd be interested to know your findings. Kind regards Bob
