On each Loop, try formstate="iteration". Here's an example:
http://jumpstart.doublenegative.com.au/jumpstart/examples/tables/editableloop1
And for T5.4:
http://jumpstart.doublenegative.com.au/jumpstart7/examples/tables/editableloop1
Cheers,
Geoff
On 16/04/2014, at 12
On Tue, Apr 15, 2014 at 2:31 PM, Thiago H de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Tue, 15 Apr 2014 07:48:47 -0300, Luke Wilson-Mawer <
> lukewilsonma...@gmail.com> wrote:
>
> A slightly more significant departure might be to start replacing your
>> pages and components with stateles
I am trying to build a form where there are N instances of a custom editing
component. For example, something simple like:
http://tapestry.apache.org/schema/tapestry_5_3.xsd";>
${idx} :
Id: :
B:
The component Java code is trivial:
public class EditObject {
@Property
Hi Thiago,
Ok, I see, thanks a lot. Meanwhile I restored the render variable by
reloading it using the value handled over in the select to the valueChanged
event - and now it works pretty good!
Regards
Eric
On Tue, 15 Apr 2014 10:26:45 -0300, "Thiago H de Paula Figueiredo"
wrote:
> On Tue, 15
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
On Tue, 15 Apr 2014 07:48:47 -0300, Luke Wilson-Mawer
wrote:
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 this with a couple of
our components, moving
On Tue, 15 Apr 2014 08:59:16 -0300, Erich Gormann
wrote:
Hi there,
Hi!
Problem description: I'am working with a tapestry form containing a loop
iterating over a bean collection. Inside the loop component a zone
component is nested.
Loop variables are no stored between requests nor they
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 there,
I'am new to that list and want to say hello to every one here.
Problem description: I'am working with a tapestry form containing a loop
iterating over a bean collection. Inside the loop component a zone
component is nested. The client side zone id is calculated from a hard
coded prefi
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 guys.
We have used the recipe for Exception reporting - version 3
http://tapestry.apache.org/overriding-exception-reporting.html
This way we can render the exception page with the current uri (no redirect
and proper 40x).
The website have both http and https pages (@Secure).
The problem we'r
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
13 matches
Mail list logo
