doRender() is an internal sounding name. Page.doRender() is entirely
internal:
/**
* THIS METHOD IS NOT PART OF THE WICKET PUBLIC API. DO NOT CALL IT.
*/
public final void doRender()
that was the original plan anyway.
since render() is a public sounding name, i would expect that to be
public api. if it was internal it should have a comment like above and
possibly also be called internalRender(). it's all very confusing right
now. i'd like for it to make intuitive sense somehow...
Juergen Donnerstag wrote:
Page.doRender is used from the target to render a Page.
Component.doRender is called from the target to re-render a component.
Why is it more logial to call Page.doRender for pages and
Component.render for components? IMO render() is completely internal
and should not be used by anyone. That is true for Page.render and
Component.render as well. From that point of view it wouldn't make
sense to make Component.render more intelligent.
Juergen
On 1/15/06, Jonathan Locke <[EMAIL PROTECTED]> wrote:
can't the logic for doRender() just be folded into a smarter render()
method?
and then ajaxhandler could expose a render() method which would do the most
appropriate thing to render the component that the handler is attached to...
Jonathan Locke wrote:
i'm okay with manual rendering so long as it's not through a method
called doRender(),
which sounds internal and does not differentiate itself from render().
Let the conclusion be that things are fine as they are now. If people
want to be consistent with how our request cycle works, they should
use request targets. If people want a more direct way, they render
manually. Especially in the case of AJAX, I think there is nothing
wrong with either.
Eelco
-------------------------------------------------------
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&opÌk
_______________________________________________
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&opÌk
_______________________________________________
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&opÌk
_______________________________________________
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&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
