Sounds cool. I had a couple of thoughts on this: -) It would probably be easier/safer to lift the function dojo.json.serialize from here as it may offer some more robust options for doing things:
http://trac.dojotoolkit.org/browser/branches/0.4/src/json.js I'd say we should just use the function but I'm not sure if that file was included in our last dojo build - which means another IO request.. ...If it isn't in the dojo.js file then I'd just dump it into the existing area of tapestrys core.js file that does the event argument serialization stuff. -) I'd definitely piggy back off of the existing browserevent parameter passing from client -> server and stick the serialized structure in there somewhere...You can use the generic "arguments" object that every function has access to which represents an object array of all function arguments to do this. -) The server gets a little more tricky. I would populate the BrowserEvent object with this data but make the de-serialization of it happen "just in time" only when the method / whatever way you are supposed to get the values is invoked. (getFunctionArguments? Not sure, whatever you think is best) I like your idea of deserializing the values by using the existing JSONObject stuff that we have. Sounds like a perfect way of doing it. -) 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. -) You may want to do a first pass impl that does everything up to populating the BrowserEvent and do the listener method stuff as a second step once you're happy with it. -) I'm not as concerned about any decrease in performance on the server from this but would be interested in knowing how it affects the client. FireBug has an awesome "profile" function which does exactly what it sounds like and is useful for figuring out perf bottlenecks there. -) We're also going to have to support this idea of passing in arguments to @EventListener methods in the same way that DirectLink parameters are passed eventually - so just keep that in the back of your head I guess. (not sure what difference that would make) Sounds like a good addition either way, I'm sure we can iron more things out once there is a code checkin and such. Everyone should feel comfortable making commits to trunk right now as it's only the beginning of the 4.1.3 cycle. Good idea! :) On 6/30/07, Marcus Schulte <[EMAIL PROTECTED]> wrote:
I've hacked up a small fix for https://issues.apache.org/jira/browse/TAPESTRY-1202 . For non-browser-originating events, i.e. interception of regular methods, any parameters to the intercepted method are converted to strings and passed on to the listener as service-parameters. Thus, you can do things like this: @EventListener(events="trigger", targets="clickRegions") public void onTriggered(BrowserEvent event, String firstArg, String secondArg ){ setTriggered( secondArg ); getResponseBuilder().updateComponent("result"); } when you have " trigger.clickRegions=function( arg1, arg2) {...} " in your client-side script. The content of the browserevent-/targetnode-info stays exactly as it was. However, to handle json properly, you'd have to 1. pass the json-string to your javascript method being intercepted 2. do "new JSONObject( firstArg )" manually in the listener to de-serialize your object. I think, in a lot of use-cases a plain string is enough - and converting it to JSONObject is not a lot of overhead. On the other hand I may have missed a "pre-designed" way to automatically handle incoming JSON objects in a more elegant way... Marcus -- 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
