David,
Thank you very much for your comments. For now I will just convert the
StringBuilder arguments to Writer arguments and drop the rendering to a string
idea. That change should only affect the Form and Menu widgets.
I like the idea of using the Appendable interface as an argument. Perhaps that
can be a project for another day.
-Adrian
David E Jones <[EMAIL PROTECTED]> wrote:
Yes, I agree with this approach. The most ideal thing is to always
write as directly to the writer as possible, and this even allows the
servlet container to progressively stream results to the client. Of
course, that means instead of using creating a StringWriter to use
temporarily the original writer from the response object (or wrapping
the stream from the response object) should just be passed down and
used.
What to do with error messages is a good question. In many cases an
exception will make continuing the rendering of the screen impossible
or lead to unpredictable results due to bad state. Whatever we do the
HTML produced is likely to be invalid, which is why we haven't tried
to eliminate exception and rendering error messages from the output,
either way the HTML is likely to be horked and you'll have to view
source to be sure to see the error message (stack trace, etc).
It might still be nice to separate this out and pass in an error
message list for everything to add errors to instead of going to the
writer, though that means the error messages while consolidated and
not interfering with the rest would be at the bottom of the page
instead of the top.
As for using a StringWriter instead of the HttpResponse Writer (or
output stream wrapped in a Writer), I'd vote strongly against that for
efficiency reasons. There are some memory usage issues with the
StringWriter in general, and of course performance and memory issues
in general when building the full string on the server before sending
it to the client. If we are going to build the full string before
sending anything to the client, we should at least use something more
efficient and performant like the the javolution.text.TextBuilder
object.
To do this more generically, and allow for easy changing between a
bunch of different things, we should change all Writer and
StringBuffer parameters to just use the java.lang.Appendable
interface, which both Writer and StringBuffer (and the javolution
TextBuilder) classes implement.
So, whatever we do in the ScreenWidgetViewHandler, in the screen
widget code itself the best flexibility will come from using the
Appendable interface for everything, plus adding an errorMessageList
parameter as a sister parameter to the appendable one so error
messages can be isolated and treated more independently.
-David
On May 30, 2008, at 9:27 AM, Adrian Crum wrote:
> 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 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
>>>
>>>
>>>
