You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@hlmksw.com> on 2008/05/30 01:21:15 UTC
More Screen Widget Ideas
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
Re: More Screen Widget Ideas
Posted by Jacques Le Roux <ja...@les7arts.com>.
Yes, thanks David for you detailled explanation. I had a look yesterday and even begin to write an answer to Jacopo's question. But
I did no sent it since I was not totally sure to well understand underneath reasons. Lostly I did not understand clearly the
client-server link through the Writer. It's clear now.
Thanks also to Adrian which is continuing to interest us to have a deeper knowledge of the framework.
Jacques
From: "Adrian Crum" <ad...@yahoo.com>
> 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 <jo...@hotwaxmedia.com> 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
>>>>
>>>>
>>>>
>
>
>
>
Re: More Screen Widget Ideas
Posted by Adrian Crum <ad...@yahoo.com>.
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 <jo...@hotwaxmedia.com> 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
>>>
>>>
>>>
Re: More Screen Widget Ideas
Posted by David E Jones <jo...@hotwaxmedia.com>.
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 <ja...@gmail.com> 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
>>>
>>>
>>>
Re: More Screen Widget Ideas
Posted by Adrian Crum <ad...@hlmksw.com>.
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 <ja...@gmail.com> 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
>>
>>
>>
>
>
Re: More Screen Widget Ideas
Posted by Jacopo Cappellato <ja...@gmail.com>.
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 <ja...@gmail.com> 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
>
>
>
Re: More Screen Widget Ideas
Posted by Adrian Crum <ad...@yahoo.com>.
That is a very good point. I will look into it.
-Adrian
Jacopo Cappellato <ja...@gmail.com> 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
Re: More Screen Widget Ideas
Posted by Jacopo Cappellato <ja...@gmail.com>.
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