You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Yves Sy <yv...@gmail.com> on 2005/05/04 05:24:16 UTC
Convention on listeners/actions handling
Hi,
Just wondering what the general consensus is on where to "handle"
operations leading to another page... It seems there are 2 approaches:
1. Handle the calls to service layer on the current page and just
activate the next page at the end of the listener method;
2. Get the next page and pass execution (and the cycle) to that next
page by calling a method from that page right away...
Br,
-Yves-
--
A bus station is where a bus stops. A train station is where a train
stops. On my desk I have a work station...
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Convention on listeners/actions handling
Posted by Yves Sy <yv...@gmail.com>.
That's what I figured out myself. Basically when the code can get
called from several places...
Thanks,
-Yves-
On 5/10/05, Kent Tong <ke...@cpttm.org.mo> wrote:
> Yves Sy <yves.sy <at> gmail.com> writes:
>
> >
> > Its very common yet you couldn't give a straight answer!
> >
> > I AM bothered because I'd want some convention on where to put logic
> > (actually, controller logic NOT biz logic), or at least a rule of
> > thumb that everyone on a team should follow. I wouldn't want one guy
> > to do something one way and another guy doing it another way...
>
> well, if you really want a straight answer, you can apply
> the following simple principle: Do you have duplicate code?
> If yes, extract it to put it where it belongs. If no, the
> logic is probably in the right place.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
A bus station is where a bus stops. A train station is where a train
stops. On my desk I have a work station...
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Convention on listeners/actions handling
Posted by Kent Tong <ke...@cpttm.org.mo>.
Yves Sy <yves.sy <at> gmail.com> writes:
>
> Its very common yet you couldn't give a straight answer!
>
> I AM bothered because I'd want some convention on where to put logic
> (actually, controller logic NOT biz logic), or at least a rule of
> thumb that everyone on a team should follow. I wouldn't want one guy
> to do something one way and another guy doing it another way...
well, if you really want a straight answer, you can apply
the following simple principle: Do you have duplicate code?
If yes, extract it to put it where it belongs. If no, the
logic is probably in the right place.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Convention on listeners/actions handling
Posted by Yves Sy <yv...@gmail.com>.
Its very common yet you couldn't give a straight answer!
I AM bothered because I'd want some convention on where to put logic
(actually, controller logic NOT biz logic), or at least a rule of
thumb that everyone on a team should follow. I wouldn't want one guy
to do something one way and another guy doing it another way...
On 5/8/05, Kent Tong <ke...@cpttm.org.mo> wrote:
> Yves Sy <yves.sy <at> gmail.com> writes:
>
> > Well of course for getting input you use (1), but I've seen samples
> > even in the Tapestry in Action book where it goes like:
> >
> > public void myLinkCliked(IRequestCycle cycle) {
> > NextPage n = (NextPage) cycle.getPage("nextPage");
> > n.showNextPage(cycle);
> > }
> >
> > ..which uses (2).
> >
> > Of course the code in n.showNextPage() could easily be in
> > myLinkClicked() and would work the same...
>
> That really depends what showNextPage() does and is a question
> of where the logic should reside. However, I wouldn't bother
> much as this issue is very cmomon in our daily programming
> life (which class to put this method?).
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
A bus station is where a bus stops. A train station is where a train
stops. On my desk I have a work station...
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Convention on listeners/actions handling
Posted by Kent Tong <ke...@cpttm.org.mo>.
Yves Sy <yves.sy <at> gmail.com> writes:
> Well of course for getting input you use (1), but I've seen samples
> even in the Tapestry in Action book where it goes like:
>
> public void myLinkCliked(IRequestCycle cycle) {
> NextPage n = (NextPage) cycle.getPage("nextPage");
> n.showNextPage(cycle);
> }
>
> ..which uses (2).
>
> Of course the code in n.showNextPage() could easily be in
> myLinkClicked() and would work the same...
That really depends what showNextPage() does and is a question
of where the logic should reside. However, I wouldn't bother
much as this issue is very cmomon in our daily programming
life (which class to put this method?).
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Convention on listeners/actions handling
Posted by Yves Sy <yv...@gmail.com>.
Well of course for getting input you use (1), but I've seen samples
even in the Tapestry in Action book where it goes like:
public void myLinkCliked(IRequestCycle cycle) {
NextPage n = (NextPage) cycle.getPage("nextPage");
n.showNextPage(cycle);
}
..which uses (2).
Of course the code in n.showNextPage() could easily be in
myLinkClicked() and would work the same...
I'm a bit concerned about this because I've already seen some code in
a project where it got quite inconsistent (using both 1 and 2) and I
found it messy.
On 5/6/05, Kent Tong <ke...@cpttm.org.mo> wrote:
> Yves Sy <yves.sy <at> gmail.com> writes:
>
> > 1. Handle the calls to service layer on the current page and just
> > activate the next page at the end of the listener method;
> > 2. Get the next page and pass execution (and the cycle) to that next
> > page by calling a method from that page right away...
>
> (1), otherwise how can you get the user input?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
A bus station is where a bus stops. A train station is where a train
stops. On my desk I have a work station...
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Convention on listeners/actions handling
Posted by Kent Tong <ke...@cpttm.org.mo>.
Yves Sy <yves.sy <at> gmail.com> writes:
> 1. Handle the calls to service layer on the current page and just
> activate the next page at the end of the listener method;
> 2. Get the next page and pass execution (and the cycle) to that next
> page by calling a method from that page right away...
(1), otherwise how can you get the user input?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org