Jacopo,
Thank you very much for your comments!
I spent some time researching the StringBuffer versus StringBuilder
issue, and the general agreement in the Java community is that there
isn't a significant performance difference. So, I'll drop the idea of
using StringBuilder.
I would still like to have the screen widgets render to a string before
writing to the browser, so I'm considering using a StringWriter for the
initial rendering - which will be output to the browser if there are no
errors. This approach would have less of an impact on the widget library
API.
If rendering large XML files via the form widget is an issue, it would
have surfaced already - since the form widget currently uses a
StringBuffer for rendering. I'll perform some tests on large datasets to
check for out-of-memory errors.
To summarize: I'd like to make the screen widget library API more
consistent by converting StringBuffer arguments to Writer (which would
be a StringWriter). Plus, have the screens rendered to a string before
being output to the client - to facilitate better error handling.
-Adrian
Jacopo Cappellato wrote:
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
