Re: Convention on listeners/actions handling

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Convention on listeners/actions handling

Kent Tong
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Convention on listeners/actions handling

Yves Sy
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Convention on listeners/actions handling

Kent Tong
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Convention on listeners/actions handling

Yves Sy
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Convention on listeners/actions handling

Kent Tong
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Convention on listeners/actions handling

Yves Sy
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
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: [hidden email]
For additional commands, e-mail: [hidden email]