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 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. 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? 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: http://click.1134972.n2.nabble.com/Click-web-architecture-questions-services-transactions-etc-tp4967590p4967590.html Sent from the click-user mailing list archive at Nabble.com.
