> pages and components with stateless rest endpoints using Tynamo's
>> tapestry-resteasy, a piece at a time. We've done this with a couple of
>> our components, moving them into angularjs.
>>
>
> This is a webapp rewrite almost from scratch (at least the web UI part)
&g
On Tue, 15 Apr 2014 07:14:41 -0300, Ben Titmarsh
wrote:
Hi Everyone,
Hi!
So what I'd like to know is how should I be tackling this in Tapestry
5.3? I had a look around and found the third party Tynamo library that
has a conversational state implementation but it doesn't look like it's
components, moving them into angularjs.
This is a webapp rewrite almost from scratch (at least the web UI part)
and doesn't really solve the problem of over-reliance on session storage.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http:/
I only use the HttpSession as a last resort. I will always favour the
stateless approach using:
1. Page activation context (onActivate() / onPassivate() or
@PageActivationContext)
2. Event context (actionlink / eventlink)
3. Posting hidden inputs
One caveat to this is that the logged in user is al
Just switching to @PageActivationContext and @ActivationRequestParmeter
will solve most of your problems.It's also best if your components are
stateless.
On Tue, Apr 15, 2014 at 5:14 AM, Ben Titmarsh wrote:
> Hi Everyone,
>
> My application is under a level of load where I am starting to regret
Hi Ben,
Have you tried using Tapestry's client persistence? I'm not up to speed
with how well it works now.
A slightly more significant departure might be to start replacing your
pages and components with stateless rest endpoints using Tynamo's
tapestry-resteasy, a piece at a time. We've done thi
Hi Everyone,
My application is under a level of load where I am starting to regret a
somewhat naive over reliance on the @Persist annotation. My pages probably
contain far too much state and as a result my memory utilisation is going
through the ceiling and I'm having to perform semi-regular r
