> its too much overhead and setup just to get an html string back - which is > what it really is.
Why not render each normal request like this too then? You can do that if you want too ;) > but then again this is my pesonal preference. That was my point. At this time I don't have a strong preference for either. > i would like there to be only > one way to do this though to keep things simpler and more straight forward. > whether that be a request target or direct invocation on the component's > render method i dont know. I don't think we have to impose that. IF we would impose it, it should be request targets as that is consistent with how normal requests work. But again, I don't think we should. It is fine if people can choose here. > i like the simplicity of the direct invocation. it requires much less work > and i can decide which components to update inside my ajax handler while its > executing. A combined request target would actually take less work if we have it. And you could decide which components to update just the same. Just a matter of how the request target is implemented. also when debugging the ajax handler you dont need to walk the > request processor to see what its doing, etc. its a shorter path imho. That is true. But the same holds for the normal request processing; instead of using the proper target, you could set a null target and manually render the page. Let the conclusion be that things are fine as they are now. If people want to be consistent with how our request cycle works, they should use request targets. If people want a more direct way, they render manually. Especially in the case of AJAX, I think there is nothing wrong with either. Eelco ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
