On Tue, Jul 26, 2011 at 11:48 PM, nillehammer <
[email protected]> wrote:
>
> Dragan Sahpaski wrote:
> >
> > Interesting,
> > As I never had used annotations for event handlers in any project so far.
> > I choose the name of the event to imply what is needed to be done in the
> > method, which I prefer to keep it as short as possible (3-4 lines of
> > code, rarely any more).
> >
> Same with me. My methods also mostly contain no more than a few lines. But
> to get to know, what is done, one would have to read the source code and
> hopefully understand it.
>
Wow, thanks for they example, that certainly points out the advantage of
using the annotation approach instead of the naming convention approach.
I'm just not sure why I've never used it. Guess I never thought about this
advantage too much. Thanks for the example once again.
Another advantage of the annotation approach would be that it can be easy to
rename an event during development of a custom component for example by
using @OnEvent(value=MyEvents.SOME_EVENT), using simple refactor->rename in
an IDE. This doesn't happen with tapestry events I suppose because they are
considered as a public api, but can clearly happen during development of
some t5 project using new events.
Also, sorry for stealing the thread :)
Cheers,
Dragan Sahpaski
>
> To give you simple example:
> Imagine someone would have to read your code (perhaps even you in 6 monts)
> trying to figure out what's going on. First aproach event handler with
> naming convention:
>
> final Class<Success> onSuccessFromForm() {
> // Ok, he's handling the succsess event of the form. But what's he doing?
>
> this.dao.save(this.entity);
> // Ah, he has saved an entity using a dao.
>
> return Success.class;
> // He returns a Success.class. Hmm, why is he doing that?
> // ... read Tapestry documentation... come back here
> // Ok, Success.class is in the pages subpackage and returning classes
> // from there means to forward to the particular page.
> }
>
> Now Annotation aproach with meaningfull name:
> @OnEvent(value="success", component="form")
> final Class<Success> storeEntityAndForwardToSuccess() {
> // Ok, got it he saves an entity and forwards to Success.
> // I'm not interested in HOW he does it and am glad not to have
> // to read any further.
>
> this.dao.save(this.entity);
> return Success.class;
> }
>
> I know this example may be a bit over simplified, but I hove you got my
> point.
>
> Lastly I want to apologize to George for stealing his thread. I am glad to
> discuss code styling matters, but perhaps we should open a new thread for
> that.
>
> Cheers nillehammer
>
>
>
>
> -----
> http://www.winfonet.eu
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Form-using-both-a-zone-and-no-zone-tp4635695p4636545.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
