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 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 (eg.
my GenericEditPage can be activated via "companyId" *or* "employeeId"
parameter, both of type Long, not to mention search page results etc..). I
don't say there is no way to achieve this, but it's always *way more*
complicated than it should be for such a common case.
Any other web framework would probably have something like (Spring example):
public String myRenderRequestHandler(
@RequestParam(value = "employeeId", required = false) Long employeeId,
@RequestParam(value = "companyId", required = false) Long companyId,
) {
...
}
and that's it. Of course, parameters are passed here as part of URL query
parameters and URL path, not very RESTful, but non-trivial pages are most
easily reaqlized in such way, and I can assure you that many products out
there don't care whether URLs are RESTful (my company does only internal web
administration consoles for our products for 10 years now, and we never
cared for RESTful URLs; I know this is different in cases of public web
sites).
And finally, with 5.2. release, we got @ActivationRequestParameter
annotation, and I felt relieved. Finally!
I converted all my pages to use this new annotation parameters instead of
URL path, and these non-trivial pages became suddenly 10x simplier. I
thought most of users of T5.2 will use this new way instead of URL path
since it is soooo much more flexibile.
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 all these parameters inside onActivate() method. Not to mention that in
some pages I didn't even have this onActivate() method since I didn't need
it, but now I had to introduce it.
I reported the improvement issue here:
https://issues.apache.org/jira/browse/TAP5-1290
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.
Then 5.2.1 version introduced new regression bug regarding this annotation
that could affect web pages when in class hierarchy:
https://issues.apache.org/jira/browse/TAP5-1311
The thing that suprised me is that there is no interest in mailing list so
much regarding this annotation, and there was of course no votes for these
of my issue report mentioned. It seems as if this long-awaited feature is
slipping through my fingers, so that's why I post this here.
C'mon people, try using this annotation and you'll see how much easier this
way of passing parameters is!
BTW, there is one more benefit of using annotation like this - not only it
makes parameter fields more visible in page class, but it also makes
parameter setting separated from pre-processing logic placed in
onActivate(). This gives much cleaner way to express some things.
Cheers,
Vjeran
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
