Maybe there are some tools available in this area that could help.
For example, I remember that in the Apache Commons there is an API to
facilitate file uploads: the file is uploaded into memory but if,
during the upload, it exceeds a configurable size, it is temporarly
stored in the file system.
Maybe there are similar tools for what we need... maybe not.
Jacopo
On May 30, 2008, at 3:24 PM, Adrian Crum wrote:
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
