i used the stream in my example because thats what the components write to. currently they are hardwired to write to the response's stream, and this is part of the problem which requires response swapping. if we had a method that took the output stream directly things would be easier, and the old method can invoke this one and pass in the response stream.
but then again this is my pesonal preference. 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 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. 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.
-Igor
On 1/14/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
I think that as both techniques are highly taste specific, it is okay
to support them both. Making a combined request target sounds like a
work around, I agree, though it hides the details of rendering more
than when you directly use the outputstream and components. Also, you
would probably use some seperation markup as if you render more than
one component and send that back to the client, you most likely want
to interpret that client side to see where the different parts should
go. A request target could encapsulate generating such seperation
markup.
Eelco
On 1/14/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> i dont like using a target to render components. it feels more of a work
> around. i would like my handler code to look like this:
>
> onAjaxCallback() {
> Component a=page.get("...");
> Component b=page.get ("....");
>
> OutputStream stringStream=....
> a.onBeginRequest();
> a.render(stringStream);
> a.onEndRequest();
>
> b.onBeginRequest();
> b.render(stringStream);
> b.onEndRequest();
>
> return stringStream;
>
> }
>
> maybe have a convinience function to called render(Component, OutputStream )
> in the ajax handler that would call onbegin/endrequest.
>
> but i am in total control of what components i wish to render and where
> their output is going. i dont need any, imho goofy, response swapping, etc.
>
> and another thing. what we need is a way to render only the body of the
> component easily because most of the time in an ajax response you only want
> to swap out the body not the tag.
> right now you have to call setrenderbodyonly and then restore its state,
> which is again goofy.
>
>
> in my sandbox i have render(OutputStream) renderBody(OutputStream) and i
> think it works great, as far as 1.2 im not sure what the best way is.
>
> -Igor
>
>
>
>
> On 1/14/06, Eelco Hillenius <[EMAIL PROTECTED] > wrote:
> >
> > We could make a special target for that I guess. Not sure whether that
> > is more elegant though... What do you think?
> >
> > Eelco
> >
> >
> > On 1/14/06, Igor Vaynberg <[EMAIL PROTECTED] > wrote:
> > > what if you want to render more then one component in a single ajax
> request?
> > > can you do that via setting the request target?
> > >
> > > -Igor
> > >
> > >
> > >
> > > On 1/14/06, Eelco Hillenius < [EMAIL PROTECTED]> wrote:
> > > >
> > > > Martijn told me a couple of days ago that instead of directly
> > > > requesting a component to render itselve, he just set the proper
> > > > request target (I think that is ComponentRequestTarget) instead. I
> > > > think that's much more elegant.
> > > >
> > > > Eelco
> > > >
> > > >
> > > > On 1/14/06, Jonathan Locke < [EMAIL PROTECTED]> wrote:
> > > > >
> > > > > but all these ajax components are using doRender()...
> > > > > and it's confusing how doRender() differs from render().
> > > > > you can't tell just from the name. can we somehow
> > > > > collapse the two logically?
> > > > >
> > > >
> > > >
> > > >
> -------------------------------------------------------
> > > > 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&opclick
> > > > _______________________________________________
> > > > Wicket-develop mailing list
> > > > [email protected]
> > > >
> > >
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> > > >
> > >
> > >
> >
> >
> > -------------------------------------------------------
> > 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&opclick
> > _______________________________________________
> > Wicket-develop mailing list
> > [email protected]
> >
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >
>
>
-------------------------------------------------------
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&opclick
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
