I am using the ComponentRequestTarget to render my component, using the
ajax prototype example as a guide. Implementing an IRequestTarget just
to set the content type seems like too much work. On the other hand,
having the RequestTarget create the xml envelope rico expects would get
rid of my ugly hack of detecting what kind of target is performing the
rendering inside the RicoEnvelopeBehavior. (as a side question, how
would I have a behavior remove itself from a component after rendering?)
Maybe this could also permit multiple, non-nested components to be
rendered in the same request.
Would the implementation of respond look something like this:
/**
* @see wicket.IRequestTarget#respond(wicket.RequestCycle)
*/
public void respond(final RequestCycle requestCycle)
{
// set content-type
final Response res = requestCycle.getResponse ();
res.setContentType ("text/xml");
// Initialize temporary variables
Page page = component.getPage();
if (page != null)
{
page.startComponentRender(component);
}
// Let component render itself
if (component instanceof Page)
{
// Use the default Page request target, if component is
a Page
new
PageRequestTarget((Page)component).respond(requestCycle);
}
else
{
// Start outer Rico Envelope
res.write ("<ajax-response>");
// start component rico envelope
// Assumes wicket:id and dom id are the same
res.write ("<response type=\"element\" id=\""
+ component.getId () + "\">"
// Render the component
component.doRender();
// close component rico env
res.write ("</response>");
//close outer rico env
res.write ("</ajax-response>");
}
if (page != null)
{
page.endComponentRender(component);
}
}
thx,
jim
Juergen Donnerstag wrote:
I'm currently trying to (performance) improve the header
implementation and AjaxHandler and IBehaviourListener are getting into
my way all the time. The more I think about them the less I like them.
I like the ajax prototype implemention in the examples much better.
And I agree with you (Johan) that a RicoComponentRequestTarget would
be my choice as well.
Juergen
On 1/21/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
What call are you using to render that component?
because now the ComponentRequestTarget doesn't set any headers i think .
You could implement youre own request target that does this.
and in the response method:
public void respond(final RequestCycle requestCycle)
{
<<<<<<<<<<<<<< set the headers here.. should work.
// Initialize temporary variables
Page page = component.getPage();
if (page != null)
{
page.startComponentRender(component);
}
// Let component render itself
if (component instanceof Page)
{
// Use the default Page request target, if component is a Page
new
PageRequestTarget((Page)component).respond(requestCycle);
}
else
{
// Render the component
component.doRender();
}
if (page != null)
{
page.endComponentRender(component);
}
}
We have to see if we must have build in support for this. Or that it has to
be done by something else like the AjaxHandler or something?
johan
On 1/21/06, Jim McLaughlin <[EMAIL PROTECTED]> wrote:
Hi,
I'm experimenting with Ajax component rendering using the openrico
library. rico expects the response to be wrapped in xml, ie
<ajax-response><response type="element" id="elementId"> <your/><data/>
</response></ajax-response>
I created a transformer to do this, which works fine, but I also need
to set the mime type to "text/xml". I saw this discussed on the list a
few months back and the consensus was to override the getMarkupType
method, but the object I am ajax rendering is a Panel, and that method
is final. Also, I only want the mime type to be text/xml when ajax
rendering is being performed, and text/html otherwise.
I tried setting it with RequestCycle.get ().getResponse
().setContentType ("text/xml"); but this didn't work. Viewing the
response with LiveHTTPHeaders didn't even show a Content-Type in the
header. I set the content type in the transform method of my
transformer, so maybe this is the problem. Where is the right place to
set the content type?
thx,
jim
-------------------------------------------------------
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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
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://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642
-------------------------------------------------------
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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
