With regard to Spring and stateful pages the SpringClickServlet option 3. "Click instantiated Pages with injected Spring beans and/or ApplicationContext"
http://click.apache.org/docs/extras-api/org/apache/click/extras/spring/SpringClickServlet.html This option could be modified to set the Spring Beans when Page instance is activated to better support stateful pages: http://click.apache.org/docs/extras-api/org/apache/click/extras/spring/SpringClickServlet.html#activatePageInstance(org.apache.click.Page) regards Malcolm Edgar On Tue, Apr 27, 2010 at 10:48 PM, Bob Schellink <[email protected]> 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: 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 > > >
