That is a very good point. I will look into it.
-Adrian
Jacopo Cappellato <[EMAIL PROTECTED]> wrote: Adrian,
I think that we should also take into account the possibility to use
the form widget to render big lists (such as an xml export)... could
the StringBuilder approach cause OutOfMemory errors?
Jacopo
On May 30, 2008, at 1:21 AM, Adrian Crum wrote:
> The current screen widget view handler creates a Writer instance and
> passes it to the screen renderer. That in turn passes the Writer
> instance to the screen's sub-widgets.
>
> Some of the sub-widgets render to a StringBuffer first, then output
> the StringBuffer contents to the Writer instance. This has led to an
> inconsistent API in the screen widget library - some methods take a
> Writer argument, others take a StringBuffer argument. (Take a look
> at the HtmlWidgetRenderer class - two versions of each method are
> needed.)
>
> One of the problems with screen widget renderers outputting to a
> Writer instance is when an error or exception occurs. The error
> message is mangled or unreadable - depending upon where in the
> Writer stream the error occurred. I'm sure most of the developers
> have seen this - where an exception is rendered inside a table
> element, or inside a drop-down list box, or inside a menu item, etc.
>
> Here's my idea: Have the screen widget view handler create a
> StringBuilder instance and pass that to the screen renderer. All
> screen sub-widgets render to the StringBuilder instance. If the
> entire process completes without errors, then the view handler
> outputs the StringBuilder contents to the Writer. If an error
> occurs, the view handler discards the StringBuilder contents and
> constructs a simple page to render the error message.
>
> The StringBuilder class should provide faster rendering, because
> it's not synchronized like the StringBuffer class. Synchronization
> is not an issue in this case.
>
> The screen widget library API would be simplified.
>
> What do you think?
>
> -Adrian
