You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Vjeran Marcinko <vj...@email.t-com.hr> on 2010/11/02 08:08:08 UTC
Let's make @ActivationRequestParameter first-class citizen
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Let's make @ActivationRequestParameter first-class citizen
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Wed, 03 Nov 2010 04:45:07 -0200, Vjeran Marcinko
<vj...@email.t-com.hr> 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, you have "companyId" page context 'cause
> you have to know which company this employee will belong to, once
> created.Both cases have just one argument in context, so using plain
> onActivate(Long argument) would not work.
I don't think using a single parameter that means two different things is
a good idea. You can use the employee id as an activaction context
parameter and the company id as a query parameter. Better yet: inject the
page, set anything you want, return it. You'll need some flash persistence
anyway. ;)
> Of course, simple workaround for this would be additional context
> argument that would provide differentiation, but I think the example is
> good. In more complex cases this would be really troublesome (such as I
> mentioned previously).
That's a scenario most suitable for query parameters, no doubts. Or,
better yet, inject the page, set anything you want, return it.
> Bottom line of my thinking is that differentiation of page render
> parameters is much more flexibile via naming than via ordering/count
> mechanism, and that's why I love @ActivationRequestParameter way.
I'm not saying for you to not use @ActivationRequestParameter. ;)
> I appreaciate the effort Thiago, but I'm not convinced. :)
>
> I picked Tapestry among other web frameworks primarely because it
> (mostly) allows me to use natural, compile-safe way to reference
> instances/fields. For eg:
You're using the strong static typing argument for a fervorous proponent
of strong static typing. :)
> @InjectPage
> private EmployeePage employeePage;
> ...and then somewhere in my web...
> if (employeePage.getEmployeeId() == ...)
>
> This referencing employeeId field in page class is so natural java
> programming. I don't need to think about URL params here, their indices
> etc. The same when I generate links (for redirect let's say):
> return employeePage.configuredWithId(31231);
I love this argument of Tapestry too. I was just saying that, in your
scenario, I would move the some logic from base classes to a
ComponentRequestFilter. I've done this before without feeling dirty. I
felt very good, by the way. :)
> This fields can be @Persist, or @Sessionstate, or whatever, everything
> is always natural and comile-safe. I just reference them.
> As I see it, ComponentRequestFilters just don't provide this level of
> commodity. I also consider them as a "advanced" usage of Tapestry,
> because I guess average Joe just don't want to know about internal
> ApplicationStateManager or ComponentEventLinkEncoder or such.
You're using word "internal" here in a way that clashes with the way it
has been used since the first Tapestry alpha version.
"Internal" in Tapestry means anything that is inside a package named
internal and the Tapestry team doesn't guarantee any
backward-compatibility in future realeases, so they shouldn't be used.
ComponentRequestFilter and ComponentEventLinkEncoder are *not* internal. I
don't consider their use basic nor advanced. Once you're given your first
steps in Tapestry, you will have some very interesting scenarios which are
better implemented using the awesome Tapestry infrastructure.
> He should know it if he's doing something unconventional, but I really
> think I'm trying to develop just usual web functionality here, nothing
> fancy.
That's my point here: using ComponentRequestFilter and
ComponentEventLinkEncoder is *not* unusual at all.
> I know inheritance can be really bad if overused (Howard's main problem
> with Tapestry versions prior to v5 was inheritance), but as I said, in
> simple cases when I spot 2-3 of my pages have some common preprocessing
> logic, I really think superclass is the way to go.
I thought you were not talking about a couple classes . . .
> I guess at the end, we can agree to disagree. :)
Yeah! :)
> users. For eg, I completely dislike class reloading for all the
> packaging (and other) burden it gives me where I can see others
What packaging problems? I'm not following you.
> People seem not to care so much of compile-safety whereas it is for me
> *by far* Tapestry's biggest selling point.
Live class reloading is a major selling point for Java frameworks, even
when compared to dynamically-typed languages. I really don't have your
impression that people don't appreciates the compile-time safety of
Tapestry. Where do you get it from?
> I guess we all differ.
And that's a very good thing.
--
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Let's make @ActivationRequestParameter first-class citizen
Posted by Vjeran Marcinko <vj...@email.t-com.hr>.
Hello again,
----- Original Message -----
From: "Thiago H. de Paula Figueiredo" <th...@gmail.com>
To: "Tapestry users" <us...@tapestry.apache.org>
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 different object ids being
> used in the same page to edit or view the same object. Of course, I don't
> know your requirements, but that's something I wouldn't do, as the same
> thing would have two or more URLs.
My example was definetly stupid, I made up the parameter names out of my
head, it's not something I have in real. Pages definetly should not be
overloaded with overly different functionality.
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, you have "companyId" page context 'cause you
have to know which company this employee will belong to, once created.
Both cases have just one argument in context, so using plain onActivate(Long
argument) would not work.
Of course, simple workaround for this would be additional context argument
that would provide differentiation, but I think the example is good. In more
complex cases this would be really troublesome (such as I mentioned
previously).
Bottom line of my thinking is that differentiation of page render parameters
is much more flexibile via naming than via ordering/count mechanism, and
that's why I love @ActivationRequestParameter way.
>> For example, sometimes this cross-cutting logic needs to access
>> @PageActivationContext fields directly, but I cannot use this annotation
>> in filter implementations (maybe by parsing URLs, but that's cumbersome
>> and not compile-safe).
> You don't need to parse yourself: use the ComponentEventLinkEncoder
> service and its decodeComponentEventRequest() and
> decodePageRenderRequest() methods. For conversions, use the TypeCoercer
> services. That's exactly what Tapestry internally does.
>> Fields annotated with @SessionState are also not available (maybe
>> available through some global Tapestry service by some (?!) name, but
>> not directly referencing class field)...etc...
> Use the ApplicationStateManager service for that. Again, that's exactly
> what Tapestry internally does. @SessionState fields are replaced by method
> invocations, so there's no difference in directly accessing fields. They
> don't even exist in runtime since T5.2. Don't forget that @SessionState is
> stored by object type, not page or field name. @Persist are.
I appreaciate the effort Thiago, but I'm not convinced. :)
I picked Tapestry among other web frameworks primarely because it (mostly)
allows me to use natural, compile-safe way to reference instances/fields.
For eg:
@InjectPage
private EmployeePage employeePage;
...and then somewhere in my web...
if (employeePage.getEmployeeId() == ...)
This referencing employeeId field in page class is so natural java
programming. I don't need to think about URL params here, their indices etc.
The same when I generate links (for redirect let's say):
return employeePage.configuredWithId(31231);
This fields can be @Persist, or @Sessionstate, or whatever, everything is
always natural and comile-safe. I just reference them.
As I see it, ComponentRequestFilters just don't provide this level of
commodity. I also consider them as a "advanced" usage of Tapestry, because I
guess average Joe just don't want to know about internal
ApplicationStateManager or ComponentEventLinkEncoder or such. He should know
it if he's doing something unconventional, but I really think I'm trying to
develop just usual web functionality here, nothing fancy.
I know inheritance can be really bad if overused (Howard's main problem with
Tapestry versions prior to v5 was inheritance), but as I said, in simple
cases when I spot 2-3 of my pages have some common preprocessing logic, I
really think superclass is the way to go. Otherwise I would end up with
multitude of cumbersome filters.
I guess at the end, we can agree to disagree. :)
Sometimes, to my collegues, when we compare Tapestry with usual
request-driven web frameworks, it seems as if comparing Hibernate with JDBC.
JDBC is dead simple, everyone understands it, there is no place to wonder
how one should do something. But that's common characteristic of all
libraries that don't try to do much for you, and you're left with much
tedious tasks yourself.
When one like Howard tries to give much higher level of abstraction and
power, it's no easy task to develop such tool, you have to try out few
things that none before you did. Majority of them turn out great, and some
of them I wish stayed as usual.
Then again, I can see how opinions on certain features can vary amoung
users. For eg, I completely dislike class reloading for all the packaging
(and other) burden it gives me where I can see others appreciate it. People
seem not to care so much of compile-safety whereas it is for me *by far*
Tapestry's biggest selling point. First thing that I did was to develop my
own version of SafePagelink that can take page *instance* argument so I can
provide it via my page:
public Object getConfiguredEmployeePageForLink() {
return employeePage.configuredWithId(31231);
}
And this is not something you would rarely use so it's not important - these
are render links we're talking here, so it's the thing you use couple of
times on each web page.
I guess we all differ.
-Vjeran
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Let's make @ActivationRequestParameter first-class citizen
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 02 Nov 2010 12:33:13 -0200, Vjeran Marcinko
<vj...@email.t-com.hr> 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 philosophy. You have all the right
to do that, but don't forget it wasn't meant to be used that way. :)
Something I personally find odd is to have two different object ids being
used in the same page to edit or view the same object. Of course, I don't
know your requirements, but that's something I wouldn't do, as the same
thing would have two or more URLs.
> but cross-cutting concerns such as I mentioned are sometimes very hard
> to realize via ComponentRequestFilter since these filters don't have
> same features as Tapestry pages. Even when desired functionality can be
> achieved, you don't have same amount of compile-check as when you do it
> via page superclass.
That's a compromise, no doubts about it.
> For example, sometimes this cross-cutting logic needs to access
> @PageActivationContext fields directly, but I cannot use this annotation
> in filter implementations (maybe by parsing URLs, but that's cumbersome
> and not compile-safe).
You don't need to parse yourself: use the ComponentEventLinkEncoder
service and its decodeComponentEventRequest() and
decodePageRenderRequest() methods. For conversions, use the TypeCoercer
services. That's exactly what Tapestry internally does.
> Fields annotated with @SessionState are also not available (maybe
> available through some global Tapestry service by some (?!) name, but
> not directly referencing class field)...etc...
Use the ApplicationStateManager service for that. Again, that's exactly
what Tapestry internally does. @SessionState fields are replaced by method
invocations, so there's no difference in directly accessing fields. They
don't even exist in runtime since T5.2. Don't forget that @SessionState is
stored by object type, not page or field name. @Persist are.
> For simple page authrozation based on some @Secured-like page
> annotation, ComponentRequestFilter are probably a perfect fit, but for
> some non-trivial cases, it seems to me this is too heavyweight solution.
> Sometimes I have a small cross-cutting logic only reused in 2-3 pages,
> and maybe a dozen of such in whole web app, so it feels a bit cumbersome
> to use ComponentRequestFilters for such cases, so superclass is a good
> fit there.
Please rethink your arguments after reading this message and let's see
what happens. :) Nice discussion, by the way. :)
--
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Let's make @ActivationRequestParameter first-class citizen
Posted by Vjeran Marcinko <vj...@email.t-com.hr>.
>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 it to all page
> requests, both render and action ones.
Yes, I'm aware of "subclassing is evil" rule, but cross-cutting concerns
such as I mentioned are sometimes very hard to realize via
ComponentRequestFilter since these filters don't have same features as
Tapestry pages. Even when desired functionality can be achieved, you don't
have same amount of compile-check as when you do it via page superclass.
For example, sometimes this cross-cutting logic needs to access
@PageActivationContext fields directly, but I cannot use this annotation in
filter implementations (maybe by parsing URLs, but that's cumbersome and not
compile-safe). Fields annotated with @SessionState are also not available
(maybe available through some global Tapestry service by some (?!) name, but
not directly referencing class field)...etc...
For simple page authrozation based on some @Secured-like page annotation,
ComponentRequestFilter are probably a perfect fit, but for some non-trivial
cases, it seems to me this is too heavyweight solution. Sometimes I have a
small cross-cutting logic only reused in 2-3 pages, and maybe a dozen of
such in whole web app, so it feels a bit cumbersome to use
ComponentRequestFilters for such cases, so superclass is a good fit there.
Cheers,
Vjeran
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Let's make @ActivationRequestParameter first-class citizen
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 02 Nov 2010 10:30:52 -0200, Vjeran Marcinko
<vj...@email.t-com.hr> 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/argname1/argvalue1/argname2/argvalue2/...
>
> I consider that cumbersome. There were some other cases that would be
> too long to explain here.
I agree that something like your context parser should be added to
Tapestry. It's not hard to make a reusable one. This was discussed in the
mailing list at list once with a couple of interesting solutions. Please
post a JIRA and I'll implement it when I have time.
> 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).
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 it to all page
requests, both render and action ones.
--
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Let's make @ActivationRequestParameter first-class citizen
Posted by Vjeran Marcinko <vj...@email.t-com.hr>.
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" <th...@gmail.com>
To: "Tapestry users" <us...@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
<vj...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Let's make @ActivationRequestParameter first-class citizen
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, 02 Nov 2010 05:08:08 -0200, Vjeran Marcinko
<vj...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Let's make @ActivationRequestParameter first-class citizen
Posted by Vjeran Marcinko <vj...@email.t-com.hr>.
----- Original Message -----
From: "Kalle Korhonen" <ka...@gmail.com>
To: "Tapestry users" <us...@tapestry.apache.org>
Sent: Tuesday, November 02, 2010 8:24 AM
Subject: Re: Let's make @ActivationRequestParameter first-class citizen
> 2010/11/2 Vjeran Marcinko <vj...@email.t-com.hr>:
>> 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 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
>
> What should happen if an argument is required but not given? Just
> asking, might not be that simple to decide on common logic.
Well, maybe it's just me, but I don't see any problem with default tapestry
exception page reporting that required parameter is not present in URL query
part.
-Vjeran
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Let's make @ActivationRequestParameter first-class citizen
Posted by Kalle Korhonen <ka...@gmail.com>.
2010/11/2 Vjeran Marcinko <vj...@email.t-com.hr>:
> 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 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
What should happen if an argument is required but not given? Just
asking, might not be that simple to decide on common logic.
Kalle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org