i don't know the full details, but could the implementation details of
how the component redraws be hidden in an abstraction (perhaps in the
ajax handler class?)?
Igor Vaynberg wrote:
i really dont see the need for this extra indirection in the request
target, i think it belongs in a subclass of ajax handler. this
subclass knows how to combine the generated markup and how to invoke
the proper methods on the component. sure the target can hide the
onbegin/endrequest but i dont think its necessary. its too much
overhead and setup just to get an html string back - which is what it
really is.
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]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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
<http://ads.osdn.com/?ad_idv37&alloc_id%16865&opclick>
> > > > _______________________________________________
> > > > Wicket-develop mailing list
> > > > [email protected]
<mailto:[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
<http://ads.osdn.com/?ad_idv37&alloc_id%16865&opclick>
> > _______________________________________________
> > Wicket-develop mailing list
> > [email protected]
<mailto:[email protected]>
> >
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
<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
<http://ads.osdn.com/?ad_idv37&alloc_id%16865&opclick>
_______________________________________________
Wicket-develop mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/wicket-develop
<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_id=7637&alloc_id=16865&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
