Hi,
Yes, for all these non-trivial pages I ended up having to use
onActivate(EventContext) and it was definetly cumbersome.
If I have a page that has only 3 parameters in activation context, and all
of them are optional Longs let's say, then you have many types of
combinations allowed:
- zero parameters
- one parameter meaning "companyID"
- one parameter meaning "employeeID"
- one parameter meaning "cardID"
- two parameters meaning "companyID" and "employeeId"
- two parameters meaning "cardID" and "employeeId"
...
Search result pages have contexts like this.
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/argname1/argvalue1/argname2/argvalue2/...
I consider that cumbersome. There were some other cases that would be too
long to explain here.
Regarding cases with page hiererchy...
Lots of times you have number of web pages that are dedicated to some entity
(eg Company), and you want only Users belonging to that Company to have
access to those pages. But that doesn't mean that all such "company" pages
have "companyId" in URL, they can also have some "employeeId" that belongs
to that company (when you edit employee data).
Now, I make folowing superclass for authorizing access:
public abstract class CompanySecuredPage {
private void onActivate(EventContext context) {
Long companyId = resolveCompanyId(context);
if (companyId != httpSession.getUser().getCompany().getId())
...
}
protected abstract Long resolveCompanyId(EventContext context);
}
Now, my subclass pages are obliged to implement this method:
protected abstract Long resolveCompanyId(EventContext context);
EditEmployeePage has only "employeeId" in URL, but you resolve "companyId"
by:
return employeeDao.getEmployee(employeeId).getCompany().getId();
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 Paula Figueiredo" <thiag...@gmail.com>
To: "Tapestry users" <users@tapestry.apache.org>
Sent: Tuesday, November 02, 2010 11:38 AM
Subject: Re: Let's make @ActivationRequestParameter first-class citizen
On Tue, 02 Nov 2010 05:08:08 -0200, Vjeran Marcinko
<vjeran.marci...@email.t-com.hr> 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,
and differentation via parameter count and order is simply too cumbersome
Is it that cumbersome to have a single onActivate(EventContext context)
method? EventContext.getCount() gives you the number of parameters and
EventContext.get(int index, Class type) returns you a given ordered
parameter already converted to your desired type through TypeCoercer.
(eg. my GenericEditPage can be activated via "companyId" *or*
"employeeId" parameter, both of type Long,
My Tapestry-CRUD has a generic edition page implemented with activation
context with no problems or complexities.
not to mention search page results etc..).
Query parameters suite best when you have many parameters.
Query parameters are also perfect for cases when one has class hierarchy
of pages, where you want to place some common logic in superclass, eg.
when you have some company-related pages where all have "companyId" in
URLs beside their page-specific ones, and you want to do some logic with
this parameter. This is very cuombersome to achive when parameters are
placed in URL path.
Just have an onActivate(EventContext context) method in the top of the
hierarchy and let subclasses override it as needed. Not cumbersome in my
humble opinion.
I thought most of users of T5.2 will use this new way instead of URL
path since it is soooo much more flexibile.
C'mon people, try using this annotation and you'll see how much easier
this way of passing parameters is!
You're not used to the page activation context, while most people in this
list are, specially the ones who started learning Tapestry before 5.2.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.864 / Virus Database: 271.1.1/3232 - Release Date: 11/01/10
20:34:00
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
