thanks for the hints! 2007/6/30, Jesse Kuhnert <[EMAIL PROTECTED]>:
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.
good pointer, that's something I've looked for. -) 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.
my current impl does something very much like that. Currently it puts an array (consisting of the serialised version of the original function's args) into the content param of the bind method, under the well-known name "sp". -) 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.
I've noted that the DirectEventService is very careful not to loose any regular service(i.e. listener)-parameters when adding the BrowserEvent to them. I was somewhat reluctant to modify the BrowserEvent since this whole method-interception business did not seem to fit in entirely. But, yes, after all, it's an event on the browser. -) 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. -) 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
-- Marcus Schulte http://marcus-schulte.blogspot.com
