Yes, that is the idea

Juergen

On 1/21/06, Jim McLaughlin <[EMAIL PROTECTED]> wrote:
> 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
>


-------------------------------------------------------
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&kid3432&bid#0486&dat1642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to