click-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <malcolm.ed...@gmail.com>
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
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 <sabob1@gmail.com> 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
>
>
>

Mime
View raw message