The isAjaxRequest logic, all the if's everywhere I want to kill off like a bad nightmare. It's re-introducing an already problematic concept similar to the rewind cycle. This will probably be the hardest part. It may require changing the rendering logic of all the tapestry components slightly, but it will be worth it. I think the response builder concept will live on in one form or another, just because we don't want to tie tapestry to dojo completely. Who knows, something better may come along at some point :)
I'm thinking the AjaxWebRequest might be handleable sort of the same way that Graphics objects are handled in java AWT? Ie you can only use the "new" functionality of Graphics2 by doing something like this:
public void paint(Graphics g) {
Graphics2 g2 = (Graphics2)g;
}
That still feels a little ickerific as well, but we'll see. Maybe having it injectable won't be as much of a big deal in the next release because it will be more of a rare ocurrence. The rendering cycle just needs to be tweaked a little bit. Instead of an all at once render it might be changeable into some of the interfaces howard already has, like prepareForRender() render() afterRender(), something like that.?
On 12/3/05, Felix Sun <[EMAIL PROTECTED]> wrote:
Hi All
Any ajax component I think should both work in normal response(page refresh) and ajax response(partial refresh)
we may also need to execute script in ajax response to build widget or do some other thing.
the current situation is we need to add scripts string to includeWriter/preprocessWriter/etc.
this can not take the advantage of script processing of Tapestry.
So does something like the following looks good?
if (ajaxRequest) {
//may render somthing.
getScript().execute(cycle, getAjaxEngine().getAjaxRequest().getResponseBuilder(), scriptParms);
return;
}
Just some thoughts and maybe it is wrong. so please let me know if you have good idea about ajax response script processing.
- Felix
