On Wed, 03 Nov 2010 04:45:07 -0200, Vjeran Marcinko
wrote:
Hello again,
Hi!
Maybe the simpliest example would be EditEmployeePage which can be used
both for *creating* and *editing* an Employee.
When you edit an Employee, you have "employeeId" page context.
When you create an Employee,
Hello again,
- Original Message -
From: "Thiago H. de Paula Figueiredo"
To: "Tapestry users"
Sent: Tuesday, November 02, 2010 4:09 PM
Subject: Re: Let's make @ActivationRequestParameter first-class citizen
Something I personally find odd is to have two d
On Tue, 02 Nov 2010 12:33:13 -0200, Vjeran Marcinko
wrote:
Yes, I'm aware of "subclassing is evil" rule,
When a tool is used we can't forget that it has some design decisions. It
was meant to be used in some ways and not in others. I guess you're
stepping out a little of the Tapestry ph
Hi, Vjeran!
Hi Thiago!
Almost any kind of cross-page solution, as this scenario, is much better
implemented as a ComponentRequestFilter. You can put all the logic in a
single, easily unit tested class and with almost no effort (just a
contribution to the ComponentRequestHandler service) apply
On Tue, 02 Nov 2010 10:30:52 -0200, Vjeran Marcinko
wrote:
Hi,
Hi, Vjeran!
What I needed was parameter naming since ordering was not sufficient. I
ended up coding my own "context parser" that treats every parameter with
odd index as "name", so you have:
http:///localhost/myapp/mypage/
etId();
I practicaly forced all subclass pages to use not-so-user-friendly version
of onActivate with EventContext argument instead of usual coerced:
void onActivate(Long employeeId);
or
@PageActivationContext()
private Long employeeId;
-Vjeran
----- Original Message -
From: "Thiago H. de
On Tue, 02 Nov 2010 05:08:08 -0200, Vjeran Marcinko
wrote:
Hello all.
Hi!
URL path context and onActivate/onPassivate mechanism seemed sufficient
until I started using it for any non-trivial page. By non-trivial, I
mean any page that can be activated via different activation contexts,
- Original Message -
From: "Kalle Korhonen"
To: "Tapestry users"
Sent: Tuesday, November 02, 2010 8:24 AM
Subject: Re: Let's make @ActivationRequestParameter first-class citizen
2010/11/2 Vjeran Marcinko :
And finally, with 5.2. release, we got @A
2010/11/2 Vjeran Marcinko :
> And finally, with 5.2. release, we got @ActivationRequestParameter
> annotation, and I felt relieved. Finally!
> But, to spoil the celebration, I noticed immediately there is no way to
> specify whether query parameter is required, so I had to place manual check
> of a
Hello all.
I know this is shameless whining for my wishes, but I find it very strange
that people don't use new @ActivationRequestParameter annotation often and
notice it's shortcomings.
When I first jumped on T5, I first looked what is the way to pass parameters
between pages/links.
URL p
10 matches
Mail list logo
