Listener methods, service parameters, new idea

["Howard M. Lewis Ship" <hl...@attbi.com>]

Using indexed instead of keyed access to the service parameters was a
conscious decision.

Service parameters are supposed to be like method parameters.  Although
indexed sp's seem very limiting at first compared to, basically, passing a
Map around it was my observation that once you factor out all the plumbing
in an application URL (needed for dispatching requests), you will rarely
have more than one service parameter.  Tapestry does factor out the
plumbing.

The advantage of using indexed access vs. keyed access is a lack of
ambiguity.  When you use keys, there's always a question about spelling and
case.  Indexes are idempotent (a hard way of saying "they are what they
are").

I you absolutely must use a Map, there's a pair of static methods on the
Tapestry class  that translate between an indexed array and a Map.


Of course, now you've touched off an idea, maybe for 2.5.  What if you
listener methods could be:

public void listener(IRequestCycle cycle, int parameter0, String parameter1,
...)

? That is, make ListenerMap more flexible about recognizing listener
methods, and capable of turning the service parameters array into method
parameters.  That would be so cool!

Final self-congratulatory note:  one of the reasons that Tapestry is going
so gangbusters is because a basic design and coding philosophy of mine has
proven to work quite well.  Always start very, very strict. Remove all
ambiguity.  Make the developer work and be disciplined.  If you start
strict, you can always ease up to add new features but it can be much more
difficult to go the other way.

For example, consider listener methods.  Originally, they didn't exist.  The
DirectLink component (well, it was named Direct at the time, but that's a
different discussion), expected an instance of IDirectListener and you had
to provide it.  Every listener was an inner class, meaning that to get
anything done, you had to create an accessor method that created an instance
of an anonymous inner class that implemented the necessary method.  I would
typically have the inner class simple call a private method on my page
class.

One day while explaining this to a new team member, and seeing the reaction
on his face, I had an epiphany about using reflection.  It took maybe an
hour or two to code up, start to finish, and because of how strictly Direct
had been coded, it plugged right in (becaues the Direct component was still
getting an instance of IDirectListener).

The neat thing is that DirectLink still supports objects that implement the
IDirectListener, meaning that things other than page listener methods can be
listeners.  The engine allows for listeners, you can easily make your Visit
or Global implement listeners.  You can create new helper beans that are
listeners.  Because it is an interface, you can easily chain listeners if
you want to.

So, if I had started with listeners are a named method on the containing
page it would have been easier for developer's using Tapestry 1.0 .... but
it would have been ugly to allow listeners anywhere else, and perhaps
awkward to add this new kind of listener method I'm proposing for 2.5.
Because we started off very strict, it is relatively easy to add new
features without breaking old features.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/proposals/tapestry



> -----Original Message-----
> From: Elankath, Tarun (Cognizant) [mailto:ETarun@blr.cognizant.com] 
> Sent: Monday, March 10, 2003 3:46 AM
> To: tapestry-user@jakarta.apache.org
> Subject: Feature Request or an alternative way ?
> 
> 
> Hi list,
> 
> Right now application parameters that are available on 
> clicking on a link, need to be passed as an Object[] array. 
> Is there a way in which we can pass parameters using 
> key-value pairs instead ?
> 
> Using object arrays hardcode the order of parameters among 
> pages, which is a bit inconvenient, and may lead to conflict 
> when modified in the future. Using key-value pairs I can 
> separate the common parameter keys into a separate interface 
> of their own.
> 
> Thanks,
> Tarun
>