Yeah, I might be wrong but I think hard coding it in as a sp argument is going to make things very fragile. You could potentially introduce a new parameter type but I would initially be very much against having any of this show up in anything returned from IRequestCycle as listener parameters. .
BrowserEvent / IRequestCycle are currently both optionally matched and provided on an as needed basis when looking over the listener methods to invoke for a particular class - so as long as the ultimate impl does something similar then I guess everything should be fine. We'll see when you're done. :) On 6/30/07, Marcus Schulte <[EMAIL PROTECTED]> wrote: <snipped>
-) The listener method lookup and parameter passing logic is very tricky - > so be careful in there. If you really think you can do this in a way that > will work "as expected" for the vast majority of people then it would be > awesome .....if not - having the data available as a getter function on > the > BrowserEvent object would still be a good second option. Yep, I didn't really want to change this in any signifcant way. The beauty of my String-only approach was, that all the old signature matchin magic just worked without any change on the server-side. Just passing ?sp=Swhatever in and let the proven machinery work the Tapestry-way. But hey, wait, can't we just introduce a JSON DataSqueezer?? And transmit any String as string and any non-string as Json-Object? OK, I'm off, coding. -- Marcus Schulte http://marcus-schulte.blogspot.com
-- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
