You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Geoff Callender <ge...@attglobal.net> on 2005/08/08 14:32:47 UTC
A style question - activate with parameters
Hi,
Anyone care to comment on a style of activating pages that I've grown to like?
Instead of doing it this way - treating the next page as a bean and using
setters, eg.
public void edit(IRequestCycle cycle) {
Object[] parameters = cycle.getServiceParameters();
String accountKey = (String) parameters[0];
AccountEditPage nextPage =
(AccountEditPage) cycle.getPage("AccountEditPage");
nextPage.setAccountKey(accountKey);
cycle.activate(cycle);
}
I've been doing it this way - create an activate method that specifies the
parameters, eg.
public void edit(IRequestCycle cycle) {
Object[] parameters = cycle.getServiceParameters();
String accountKey = (String) parameters[0];
AccountEditPage nextPage =
(AccountEditPage) cycle.getPage("AccountEditPage");
nextPage.activate(cycle, accountKey);
}
The page now has a clear, explicit external interface (called activate!), and
crisp, unambiguous interfaces are good. To understand the pre-requisites
of any page you need look only at its activate(..) method signature.
Better still, the signature shows the exceptions thrown, allowing the caller
to do things like display the error on the same page:
public void edit(IRequestCycle cycle) {
Object[] parameters = cycle.getServiceParameters();
String accountKey = (String) parameters[0];
try {
AccountEditPage nextPage =
(AccountEditPage) cycle.getPage("AccountEditPage");
nextPage.activate(cycle, accountKey);
}
catch (ValidationException e) {
setErrorMessage(e.toString());
}
catch (Exception e) {
throw new ApplicationRuntimeException(e);
}
}
Here's an example of activate:
public void activate(IRequestCycle cycle, String accountKey)
throws ValidationException {
try {
setKey(accountKey);
// Access business layer, build page, etc, then activate...
cycle.activate(this);
}
catch (ValidationException e) {
throw e;
}
catch (Exception e) {
throw new ApplicationRuntimeException(e);
}
}
Any comments? Any limitations I haven't thought of, etc?
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: A style question - activate with parameters
Posted by The Chris Method <th...@gmail.com>.
Yes, I did. Whoops! I wish gmail had better code editing support.
On 8/8/05, Geoff Callender <ge...@attglobal.net> wrote:
>
> Neat idea, but did you mean this (added a "static" and made setKey() a
> non-static method)...
>
> public static void activate(IRequestCycle cycle, String accountKey)
> throws ValidationException {
> AccountEditPage nextPage =
> (AccountEditPage) cycle.getPage("AccountEditPage");
> try {
> nextPage.setKey(accountKey);
>
> // Access business layer, build page, etc, then activate...
>
> cycle.activate(nextPage);
> }
> catch (ValidationException e) {
> throw e;
> }
> catch (Exception e) {
> throw new ApplicationRuntimeException(e);
> }
> }
>
> Geoff
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: A style question - activate with parameters
Posted by Geoff Callender <ge...@attglobal.net>.
Neat idea, but did you mean this (added a "static" and made setKey() a
non-static method)...
public static void activate(IRequestCycle cycle, String accountKey)
throws ValidationException {
AccountEditPage nextPage =
(AccountEditPage) cycle.getPage("AccountEditPage");
try {
nextPage.setKey(accountKey);
// Access business layer, build page, etc, then activate...
cycle.activate(nextPage);
}
catch (ValidationException e) {
throw e;
}
catch (Exception e) {
throw new ApplicationRuntimeException(e);
}
}
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: A style question - activate with parameters
Posted by The Chris Method <th...@gmail.com>.
We do something like that, but take it a little further. The activate method
is static and gets the page from the cycle. So the activate method you
posted would look something like this:
public void activate(IRequestCycle cycle, String accountKey)
throws ValidationException {
AccountEditPage nextPage =
(AccountEditPage) cycle.getPage("AccountEditPage");
try {
setKey(accountKey);
// Access business layer, build page, etc, then activate...
cycle.activate(nextPage);
}
catch (ValidationException e) {
throw e;
}
catch (Exception e) {
throw new ApplicationRuntimeException(e);
}
}
Which will simplify your call down to:
AccountEditPage.activate(cycle, "accountKey");
On 8/8/05, Geoff Callender <ge...@attglobal.net> wrote:
>
> Hi,
>
> Anyone care to comment on a style of activating pages that I've grown to
> like?
>
> Instead of doing it this way - treating the next page as a bean and using
> setters, eg.
>
> public void edit(IRequestCycle cycle) {
> Object[] parameters = cycle.getServiceParameters();
> String accountKey = (String) parameters[0];
>
> AccountEditPage nextPage =
> (AccountEditPage) cycle.getPage("AccountEditPage");
> nextPage.setAccountKey(accountKey);
> cycle.activate(cycle);
> }
>
> I've been doing it this way - create an activate method that specifies the
> parameters, eg.
>
> public void edit(IRequestCycle cycle) {
> Object[] parameters = cycle.getServiceParameters();
> String accountKey = (String) parameters[0];
>
> AccountEditPage nextPage =
> (AccountEditPage) cycle.getPage("AccountEditPage");
> nextPage.activate(cycle, accountKey);
> }
>
> The page now has a clear, explicit external interface (called activate!),
> and
> crisp, unambiguous interfaces are good. To understand the pre-requisites
> of any page you need look only at its activate(..) method signature.
>
> Better still, the signature shows the exceptions thrown, allowing the
> caller
> to do things like display the error on the same page:
>
> public void edit(IRequestCycle cycle) {
> Object[] parameters = cycle.getServiceParameters();
> String accountKey = (String) parameters[0];
>
> try {
> AccountEditPage nextPage =
> (AccountEditPage) cycle.getPage("AccountEditPage");
> nextPage.activate(cycle, accountKey);
> }
> catch (ValidationException e) {
> setErrorMessage(e.toString());
> }
> catch (Exception e) {
> throw new ApplicationRuntimeException(e);
> }
> }
>
> Here's an example of activate:
>
> public void activate(IRequestCycle cycle, String accountKey)
> throws ValidationException {
>
> try {
> setKey(accountKey);
>
> // Access business layer, build page, etc, then activate...
>
> cycle.activate(this);
> }
> catch (ValidationException e) {
> throw e;
> }
> catch (Exception e) {
> throw new ApplicationRuntimeException(e);
> }
> }
>
> Any comments? Any limitations I haven't thought of, etc?
>
> Geoff
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: A style question - activate with parameters
Posted by Greg Ward <gw...@python.net>.
On 08 August 2005, Paul Cantrell said:
> To be honest, I'm really skeptical of the way Tapestry bends over
> backwards to reuse page objects. Object instantiation was very
> expensive in 1.1, somewhat in 1.2 ... but these day's, it's
> incredibly cheap.
But there's a lot more to a Tapestry page instance than one instance of some
IPage-implementing class: there's all the components, and whatever
sub-objects your page class references, and whatever sub-objects all the
component classes reference, etc. etc. Section 7.6 of *Tapestry in Action*
explains in more detail.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: A style question - activate with parameters
Posted by Paul Cantrell <ca...@pobox.com>.
Yes, I like it!
To be honest, I'm really skeptical of the way Tapestry bends over
backwards to reuse page objects. Object instantiation was very
expensive in 1.1, somewhat in 1.2 ... but these day's, it's
incredibly cheap.
So, I really wish I could do this:
public IPage edit(String accountKey) {
return new AccountEditPage(accountKey);
}
...or something like that. Then Tapestry could just throw away that
object when it's no longer needed, instead of all this tricky
business of clearing (or not clearing) all the properties.
Yes, yes, I know -- the abstract methods, where do the values get
filled in...but the code is so clear, so conscise, so nicely OO!
Your approach seems about as close as we'll get in Tapestry's current
architecture.
Cheers,
Paul
On Aug 8, 2005, at 7:32 AM, Geoff Callender wrote:
> Hi,
>
> Anyone care to comment on a style of activating pages that I've
> grown to like?
>
> Instead of doing it this way - treating the next page as a bean and
> using
> setters, eg.
>
> public void edit(IRequestCycle cycle) {
> Object[] parameters = cycle.getServiceParameters();
> String accountKey = (String) parameters[0];
>
> AccountEditPage nextPage =
> (AccountEditPage) cycle.getPage("AccountEditPage");
> nextPage.setAccountKey(accountKey);
> cycle.activate(cycle);
> }
>
> I've been doing it this way - create an activate method that
> specifies the
> parameters, eg.
>
> public void edit(IRequestCycle cycle) {
> Object[] parameters = cycle.getServiceParameters();
> String accountKey = (String) parameters[0];
>
> AccountEditPage nextPage =
> (AccountEditPage) cycle.getPage("AccountEditPage");
> nextPage.activate(cycle, accountKey);
> }
>
> The page now has a clear, explicit external interface (called
> activate!), and
> crisp, unambiguous interfaces are good. To understand the pre-
> requisites
> of any page you need look only at its activate(..) method signature.
>
> Better still, the signature shows the exceptions thrown, allowing
> the caller
> to do things like display the error on the same page:
>
> public void edit(IRequestCycle cycle) {
> Object[] parameters = cycle.getServiceParameters();
> String accountKey = (String) parameters[0];
>
> try {
> AccountEditPage nextPage =
> (AccountEditPage) cycle.getPage
> ("AccountEditPage");
> nextPage.activate(cycle, accountKey);
> }
> catch (ValidationException e) {
> setErrorMessage(e.toString());
> }
> catch (Exception e) {
> throw new ApplicationRuntimeException(e);
> }
> }
>
> Here's an example of activate:
>
> public void activate(IRequestCycle cycle, String accountKey)
> throws ValidationException {
>
> try {
> setKey(accountKey);
>
> // Access business layer, build page, etc, then
> activate...
>
> cycle.activate(this);
> }
> catch (ValidationException e) {
> throw e;
> }
> catch (Exception e) {
> throw new ApplicationRuntimeException(e);
> }
> }
>
> Any comments? Any limitations I haven't thought of, etc?
>
> Geoff
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
_________________________________________________________________
"After hearing ten thousand explanations, a fool is no wiser.
But an intelligent person needs only two thousand five hundred."
-- Mahabharata
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org