New FoFormRenderer class

[Jacopo Cappellato]

Hi all,

I'm implementing a new FoFormRenderer class that implements the
FormStringRenderer interface: the idea is to get fo representation of a
form widget definition.

I really hope to commit the very first version of this today, but I'd
like to get some hints about where is the code (and what is the logic)
that will instantiate the FoFormRenderer instead of FormStringRenderer
class.

Should I look at the view-map definition's "content-type" attribute in
the controller file? If so, any hints about where I can find the code
that handles this?

Thanks,

Jacopo

[David E Jones-2]

On Aug 8, 2006, at 1:11 AM, Jacopo Cappellato wrote:

> Hi all,
>
> I'm implementing a new FoFormRenderer class that implements the  
> FormStringRenderer interface: the idea is to get fo representation  
> of a form widget definition.
>
> I really hope to commit the very first version of this today, but  
> I'd like to get some hints about where is the code (and what is the  
> logic) that will instantiate the FoFormRenderer instead of  
> FormStringRenderer class.
>
> Should I look at the view-map definition's "content-type" attribute  
> in the controller file? If so, any hints about where I can find the  
> code that handles this?

It should probably be a new view-handler, ie a new class mounted at  
the top of a controller.xml file and then used in the view-map type.

On a side note, what does the FoFormRenderer do differently than the  
FormStringRenderer?

-David

[Jacopo Cappellato]

David,

ok, I managed it (I'm using the ScreenFopPdfViewHandler).

FoFormRenderer is an implementation of the FormStringRenderer interface,
exactly as the HtmlFormRenderer is an implementation of it.
So, HtmlFormRenderer is used to get an html representation of a form;
FoFormRenderer is used to get a fo representation of a form.

The final goal is to get simple PDF reports directly from a screen and
form definition.

Jacopo

David E. Jones wrote:

>
> On Aug 8, 2006, at 1:11 AM, Jacopo Cappellato wrote:
>
>> Hi all,
>>
>> I'm implementing a new FoFormRenderer class that implements the
>> FormStringRenderer interface: the idea is to get fo representation of
>> a form widget definition.
>>
>> I really hope to commit the very first version of this today, but I'd
>> like to get some hints about where is the code (and what is the logic)
>> that will instantiate the FoFormRenderer instead of FormStringRenderer
>> class.
>>
>> Should I look at the view-map definition's "content-type" attribute in
>> the controller file? If so, any hints about where I can find the code
>> that handles this?
>
> It should probably be a new view-handler, ie a new class mounted at the
> top of a controller.xml file and then used in the view-map type.
>
> On a side note, what does the FoFormRenderer do differently than the
> FormStringRenderer?
>
> -David

[Jacopo Cappellato]

Please find attached an example of my first pdf report (just a test)
generated using an already existent form widget definition
(component://accounting/webapp/accounting/agreement/AgreementForms.xml#ListAgreementItemProducts)...
isn't it nice? :-)

As soon as I'll clean up the code, I'll commit it if you all agree.

Also, I'd like to find a way to suggest to the renderer at least the
following column attributes:

1) column dimension
2) text alignment in cells (so that we can right align numbers)

What do you think? I'd really love to get your feedback since this would
  probably mean that we'll have to modify the widget-form.xsd

Thanks,

Jacopo


Jacopo Cappellato wrote:

> David,
>
> ok, I managed it (I'm using the ScreenFopPdfViewHandler).
>
> FoFormRenderer is an implementation of the FormStringRenderer interface,
> exactly as the HtmlFormRenderer is an implementation of it.
> So, HtmlFormRenderer is used to get an html representation of a form;
> FoFormRenderer is used to get a fo representation of a form.
>
> The final goal is to get simple PDF reports directly from a screen and
> form definition.
>
> Jacopo
>
> David E. Jones wrote:
>>
>> On Aug 8, 2006, at 1:11 AM, Jacopo Cappellato wrote:
>>
>>> Hi all,
>>>
>>> I'm implementing a new FoFormRenderer class that implements the
>>> FormStringRenderer interface: the idea is to get fo representation of
>>> a form widget definition.
>>>
>>> I really hope to commit the very first version of this today, but I'd
>>> like to get some hints about where is the code (and what is the
>>> logic) that will instantiate the FoFormRenderer instead of
>>> FormStringRenderer class.
>>>
>>> Should I look at the view-map definition's "content-type" attribute
>>> in the controller file? If so, any hints about where I can find the
>>> code that handles this?
>>
>> It should probably be a new view-handler, ie a new class mounted at
>> the top of a controller.xml file and then used in the view-map type.
>>
>> On a side note, what does the FoFormRenderer do differently than the
>> FormStringRenderer?
>>
>> -David

[cjhowe]

Jacopo, looks like the attachment got scrubed, could
you create a JIRA for this.  I'm VERY intersted in
this :)
--- Jacopo Cappellato <[hidden email]> wrote:

> Please find attached an example of my first pdf
> report (just a test)
> generated using an already existent form widget
> definition
>
(component://accounting/webapp/accounting/agreement/AgreementForms.xml#ListAgreementItemProducts)...

>
> isn't it nice? :-)
>
> As soon as I'll clean up the code, I'll commit it if
> you all agree.
>
> Also, I'd like to find a way to suggest to the
> renderer at least the
> following column attributes:
>
> 1) column dimension
> 2) text alignment in cells (so that we can right
> align numbers)
>
> What do you think? I'd really love to get your
> feedback since this would
>   probably mean that we'll have to modify the
> widget-form.xsd
>
> Thanks,
>
> Jacopo
>
>
> Jacopo Cappellato wrote:
> > David,
> >
> > ok, I managed it (I'm using the
> ScreenFopPdfViewHandler).
> >
> > FoFormRenderer is an implementation of the
> FormStringRenderer interface,
> > exactly as the HtmlFormRenderer is an
> implementation of it.
> > So, HtmlFormRenderer is used to get an html
> representation of a form;
> > FoFormRenderer is used to get a fo representation
> of a form.
> >
> > The final goal is to get simple PDF reports
> directly from a screen and
> > form definition.
> >
> > Jacopo
> >
> > David E. Jones wrote:
> >>
> >> On Aug 8, 2006, at 1:11 AM, Jacopo Cappellato
> wrote:
> >>
> >>> Hi all,
> >>>
> >>> I'm implementing a new FoFormRenderer class that
> implements the
> >>> FormStringRenderer interface: the idea is to get
> fo representation of
> >>> a form widget definition.
> >>>
> >>> I really hope to commit the very first version
> of this today, but I'd
> >>> like to get some hints about where is the code
> (and what is the
> >>> logic) that will instantiate the FoFormRenderer
> instead of
> >>> FormStringRenderer class.
> >>>
> >>> Should I look at the view-map definition's
> "content-type" attribute
> >>> in the controller file? If so, any hints about
> where I can find the
> >>> code that handles this?
> >>
> >> It should probably be a new view-handler, ie a
> new class mounted at
> >> the top of a controller.xml file and then used in
> the view-map type.
> >>
> >> On a side note, what does the FoFormRenderer do
> differently than the
> >> FormStringRenderer?
> >>
> >> -David
>
>

[Jacopo Cappellato]

Sorry,

here is the attachment.


Jacopo Cappellato wrote:

> Please find attached an example of my first pdf report (just a test)
> generated using an already existent form widget definition
> (component://accounting/webapp/accounting/agreement/AgreementForms.xml#ListAgreementItemProducts)...
> isn't it nice? :-)
>
> As soon as I'll clean up the code, I'll commit it if you all agree.
>
> Also, I'd like to find a way to suggest to the renderer at least the
> following column attributes:
>
> 1) column dimension
> 2) text alignment in cells (so that we can right align numbers)
>
> What do you think? I'd really love to get your feedback since this would
>  probably mean that we'll have to modify the widget-form.xsd
>
> Thanks,
>
> Jacopo
>

[Jacopo Cappellato]

Here are a few development details.
In the attached patch you'll find the only changes needed in the widget
component (I've not included the new class, that I'm still cleaning up).

* The small change to ModelForm class (new getter method) is needed
because I have to read the form's list

* I've moved the instruction:
context.put("formStringRenderer", new HtmlFormRenderer(request, response));

from the ScreenRenderer class to the ScreenFopPdfViewHandler and
ScreenWidgetViewHandler classes (so that the first one can instantiate
the new FoFormRenderer class)

That's all.
It would be great to get your feedback because I'd like to commit soon
my work... if you are uncertain and would like to test it before I
commit, let me know and I'll put everything in Jira.

Jacopo


Jacopo Cappellato wrote:

> Sorry,
>
> here is the attachment.
>
>
> Jacopo Cappellato wrote:
>> Please find attached an example of my first pdf report (just a test)
>> generated using an already existent form widget definition
>> (component://accounting/webapp/accounting/agreement/AgreementForms.xml#ListAgreementItemProducts)...
>> isn't it nice? :-)
>>
>> As soon as I'll clean up the code, I'll commit it if you all agree.
>>
>> Also, I'd like to find a way to suggest to the renderer at least the
>> following column attributes:
>>
>> 1) column dimension
>> 2) text alignment in cells (so that we can right align numbers)
>>
>> What do you think? I'd really love to get your feedback since this
>> would  probably mean that we'll have to modify the widget-form.xsd
>>
>> Thanks,
>>
>> Jacopo
>>
>

Index: framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
===================================================================
--- framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java (revision 429656)
+++ framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java (working copy)
@@ -229,9 +229,6 @@
 
         // ========== setup values that are specific to OFBiz webapps
 
-        // this is the object used to render forms from their definitions
-        context.put("formStringRenderer", new HtmlFormRenderer(request, response));
-
         context.put("request", request);
         context.put("response", response);
         context.put("session", session);
Index: framework/widget/src/org/ofbiz/widget/screen/ScreenFopPdfViewHandler.java
===================================================================
--- framework/widget/src/org/ofbiz/widget/screen/ScreenFopPdfViewHandler.java (revision 429656)
+++ framework/widget/src/org/ofbiz/widget/screen/ScreenFopPdfViewHandler.java (working copy)
@@ -32,6 +32,7 @@
 import org.ofbiz.base.util.Debug;
 import org.ofbiz.base.util.UtilXml;
 import org.ofbiz.webapp.view.ViewHandlerException;
+import org.ofbiz.widget.fo.FoFormRenderer;
 import org.w3c.dom.Document;
 import org.xml.sax.InputSource;
 
@@ -55,6 +56,8 @@
         try {
             ScreenRenderer screens = new ScreenRenderer(writer, null, htmlScreenRenderer);
             screens.populateContextForRequest(request, response, servletContext);
+            // this is the object used to render forms from their definitions
+            screens.getContext().put("formStringRenderer", new FoFormRenderer(request, response));
             screens.render(page);
         } catch (Throwable t) {
             throw new ViewHandlerException("Problems with the response writer/output stream", t);
Index: framework/widget/src/org/ofbiz/widget/screen/ScreenWidgetViewHandler.java
===================================================================
--- framework/widget/src/org/ofbiz/widget/screen/ScreenWidgetViewHandler.java (revision 429656)
+++ framework/widget/src/org/ofbiz/widget/screen/ScreenWidgetViewHandler.java (working copy)
@@ -30,6 +30,7 @@
 import org.ofbiz.webapp.view.ViewHandler;
 import org.ofbiz.webapp.view.ViewHandlerException;
 import org.ofbiz.widget.html.HtmlScreenRenderer;
+import org.ofbiz.widget.html.HtmlFormRenderer;
 import org.xml.sax.SAXException;
 
 /**
@@ -72,6 +73,8 @@
 
             ScreenRenderer screens = new ScreenRenderer(writer, null, htmlScreenRenderer);
             screens.populateContextForRequest(request, response, servletContext);
+            // this is the object used to render forms from their definitions
+            screens.getContext().put("formStringRenderer", new HtmlFormRenderer(request, response));
             screens.render(page);
         } catch (IOException e) {
             throw new ViewHandlerException("Error in the response writer/output stream: " + e.toString(), e);
Index: framework/widget/src/org/ofbiz/widget/form/ModelForm.java
===================================================================
--- framework/widget/src/org/ofbiz/widget/form/ModelForm.java (revision 429656)
+++ framework/widget/src/org/ofbiz/widget/form/ModelForm.java (working copy)
@@ -1894,6 +1894,10 @@
         return value != null ? value.intValue() : (getHighIndex(context) - getLowIndex(context));
     }
 
+    public List getFieldList() {
+        return fieldList;
+    }
+
     public void getListLimits(Map context, Object entryList) {
         int listSize = 0;
         int viewIndex = 0;

[Jacques Le Roux]

----- Original Message -----
From: "Jacopo Cappellato" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, August 08, 2006 3:37 PM
Subject: Re: New FoFormRenderer class

> Sorry,
>
> here is the attachment.
>
>
> Jacopo Cappellato wrote:
> > Please find attached an example of my first pdf report (just a test)
> > generated using an already existent form widget definition
> > (component://accounting/webapp/accounting/agreement/AgreementForms.xml#ListAgreementItemProducts)...
> > isn't it nice? :-)

Yes very nice indeed :o) and very helpfull !

Jacques

> > As soon as I'll clean up the code, I'll commit it if you all agree.
> >
> > Also, I'd like to find a way to suggest to the renderer at least the
> > following column attributes:
> >
> > 1) column dimension
> > 2) text alignment in cells (so that we can right align numbers)

My opinion : keep it as simple as possible. After one might do what one needs from that point. So this 2 parameters seems cool to
me.

Jacques

> > What do you think? I'd really love to get your feedback since this would
> >  probably mean that we'll have to modify the widget-form.xsd
> >
> > Thanks,
> >
> > Jacopo
> >
>
>

[David E Jones-2]

Jacopo,

This looks like a nice feature, so yeah please do feel free to put it  
in. The changes you described in your other email to make the form  
widget more flexible look very good.

As for the new attributes: it would be nice (or best...) if these  
could be handled through style names like we do with other things. In  
the case of an XSL:FO file you can probably use a style pattern very  
similar to CSS. The plan for other types of rendering, even desktop  
applications, is to use styles and where necessary even have our own  
style mapping files (preferably an XML file rather than a CSS type  
file or something, though an actual CSS file might be interesting the  
problem is that we might want things associated with the style in  
addition to what CSS supports).

The real point, in other words, is to keep the layout and other  
styling information as much as possible in a generic label that has  
details in a separate place so the same form with the same labels can  
be rendered for many different targets.

-David


On Aug 8, 2006, at 7:31 AM, Jacopo Cappellato wrote:

> Please find attached an example of my first pdf report (just a  
> test) generated using an already existent form widget definition  
> (component://accounting/webapp/accounting/agreement/
> AgreementForms.xml#ListAgreementItemProducts)... isn't it nice? :-)
>
> As soon as I'll clean up the code, I'll commit it if you all agree.
>
> Also, I'd like to find a way to suggest to the renderer at least  
> the following column attributes:
>
> 1) column dimension
> 2) text alignment in cells (so that we can right align numbers)
>
> What do you think? I'd really love to get your feedback since this  
> would  probably mean that we'll have to modify the widget-form.xsd
>
> Thanks,
>
> Jacopo
>
>
> Jacopo Cappellato wrote:
>> David,
>> ok, I managed it (I'm using the ScreenFopPdfViewHandler).
>> FoFormRenderer is an implementation of the FormStringRenderer  
>> interface, exactly as the HtmlFormRenderer is an implementation of  
>> it.
>> So, HtmlFormRenderer is used to get an html representation of a  
>> form; FoFormRenderer is used to get a fo representation of a form.
>> The final goal is to get simple PDF reports directly from a screen  
>> and form definition.
>> Jacopo
>> David E. Jones wrote:
>>>
>>> On Aug 8, 2006, at 1:11 AM, Jacopo Cappellato wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm implementing a new FoFormRenderer class that implements the  
>>>> FormStringRenderer interface: the idea is to get fo  
>>>> representation of a form widget definition.
>>>>
>>>> I really hope to commit the very first version of this today,  
>>>> but I'd like to get some hints about where is the code (and what  
>>>> is the logic) that will instantiate the FoFormRenderer instead  
>>>> of FormStringRenderer class.
>>>>
>>>> Should I look at the view-map definition's "content-type"  
>>>> attribute in the controller file? If so, any hints about where I  
>>>> can find the code that handles this?
>>>
>>> It should probably be a new view-handler, ie a new class mounted  
>>> at the top of a controller.xml file and then used in the view-map  
>>> type.
>>>
>>> On a side note, what does the FoFormRenderer do differently than  
>>> the FormStringRenderer?
>>>
>>> -David
>

[Jacopo Cappellato]

David, all,

thanks for your suggestions.
Unfortunately I'm not an expert of css and I could not figure out if it
it is possible to use plain css into fo template.
However I've implemented a very simple style properties file: the
*-widget-style attributes specified in the form definition are used to
retrieve the fo attributes from a properies file.
Very simple... but for now it's what I needed to get custom column sizes
and right/left alignment.
It is also possible to specify a portrait/landscape format and a few
other misc features.
A good example (and prototype) of the fo widget generator is the report
of the chart of accounts that you can get following this path:
Accounting->Chart of Accounts->Print
Please test it and help with bug fixes, enhancements and suggestions.

Jacopo

David E. Jones wrote:

>
> Jacopo,
>
> This looks like a nice feature, so yeah please do feel free to put it
> in. The changes you described in your other email to make the form
> widget more flexible look very good.
>
> As for the new attributes: it would be nice (or best...) if these could
> be handled through style names like we do with other things. In the case
> of an XSL:FO file you can probably use a style pattern very similar to
> CSS. The plan for other types of rendering, even desktop applications,
> is to use styles and where necessary even have our own style mapping
> files (preferably an XML file rather than a CSS type file or something,
> though an actual CSS file might be interesting the problem is that we
> might want things associated with the style in addition to what CSS
> supports).
>
> The real point, in other words, is to keep the layout and other styling
> information as much as possible in a generic label that has details in a
> separate place so the same form with the same labels can be rendered for
> many different targets.
>
> -David
>
>
> On Aug 8, 2006, at 7:31 AM, Jacopo Cappellato wrote:
>
>> Please find attached an example of my first pdf report (just a test)
>> generated using an already existent form widget definition
>> (component://accounting/webapp/accounting/agreement/AgreementForms.xml#ListAgreementItemProducts)...
>> isn't it nice? :-)
>>
>> As soon as I'll clean up the code, I'll commit it if you all agree.
>>
>> Also, I'd like to find a way to suggest to the renderer at least the
>> following column attributes:
>>
>> 1) column dimension
>> 2) text alignment in cells (so that we can right align numbers)
>>
>> What do you think? I'd really love to get your feedback since this
>> would  probably mean that we'll have to modify the widget-form.xsd
>>
>> Thanks,
>>
>> Jacopo
>>
>>
>> Jacopo Cappellato wrote:
>>> David,
>>> ok, I managed it (I'm using the ScreenFopPdfViewHandler).
>>> FoFormRenderer is an implementation of the FormStringRenderer
>>> interface, exactly as the HtmlFormRenderer is an implementation of it.
>>> So, HtmlFormRenderer is used to get an html representation of a form;
>>> FoFormRenderer is used to get a fo representation of a form.
>>> The final goal is to get simple PDF reports directly from a screen
>>> and form definition.
>>> Jacopo
>>> David E. Jones wrote:
>>>>
>>>> On Aug 8, 2006, at 1:11 AM, Jacopo Cappellato wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm implementing a new FoFormRenderer class that implements the
>>>>> FormStringRenderer interface: the idea is to get fo representation
>>>>> of a form widget definition.
>>>>>
>>>>> I really hope to commit the very first version of this today, but
>>>>> I'd like to get some hints about where is the code (and what is the
>>>>> logic) that will instantiate the FoFormRenderer instead of
>>>>> FormStringRenderer class.
>>>>>
>>>>> Should I look at the view-map definition's "content-type" attribute
>>>>> in the controller file? If so, any hints about where I can find the
>>>>> code that handles this?
>>>>
>>>> It should probably be a new view-handler, ie a new class mounted at
>>>> the top of a controller.xml file and then used in the view-map type.
>>>>
>>>> On a side note, what does the FoFormRenderer do differently than the
>>>> FormStringRenderer?
>>>>
>>>> -David
>>

[David E Jones-2]

I'm very much an amateur with XSL:FO, so I'm not sure if there is a  
CSS type thingy with independently defined styles, but I would be  
surprised if such a thing did not exist.

For now the properties file approach is fine.

-David


On Aug 10, 2006, at 2:36 PM, Jacopo Cappellato wrote:

> David, all,
>
> thanks for your suggestions.
> Unfortunately I'm not an expert of css and I could not figure out  
> if it it is possible to use plain css into fo template.
> However I've implemented a very simple style properties file: the *-
> widget-style attributes specified in the form definition are used  
> to retrieve the fo attributes from a properies file.
> Very simple... but for now it's what I needed to get custom column  
> sizes and right/left alignment.
> It is also possible to specify a portrait/landscape format and a  
> few other misc features.
> A good example (and prototype) of the fo widget generator is the  
> report of the chart of accounts that you can get following this path:
> Accounting->Chart of Accounts->Print
> Please test it and help with bug fixes, enhancements and suggestions.
>
> Jacopo
>
> David E. Jones wrote:
>> Jacopo,
>> This looks like a nice feature, so yeah please do feel free to put  
>> it in. The changes you described in your other email to make the  
>> form widget more flexible look very good.
>> As for the new attributes: it would be nice (or best...) if these  
>> could be handled through style names like we do with other things.  
>> In the case of an XSL:FO file you can probably use a style pattern  
>> very similar to CSS. The plan for other types of rendering, even  
>> desktop applications, is to use styles and where necessary even  
>> have our own style mapping files (preferably an XML file rather  
>> than a CSS type file or something, though an actual CSS file might  
>> be interesting the problem is that we might want things associated  
>> with the style in addition to what CSS supports).
>> The real point, in other words, is to keep the layout and other  
>> styling information as much as possible in a generic label that  
>> has details in a separate place so the same form with the same  
>> labels can be rendered for many different targets.
>> -David
>> On Aug 8, 2006, at 7:31 AM, Jacopo Cappellato wrote:
>>> Please find attached an example of my first pdf report (just a  
>>> test) generated using an already existent form widget definition  
>>> (component://accounting/webapp/accounting/agreement/
>>> AgreementForms.xml#ListAgreementItemProducts)... isn't it nice? :-)
>>>
>>> As soon as I'll clean up the code, I'll commit it if you all agree.
>>>
>>> Also, I'd like to find a way to suggest to the renderer at least  
>>> the following column attributes:
>>>
>>> 1) column dimension
>>> 2) text alignment in cells (so that we can right align numbers)
>>>
>>> What do you think? I'd really love to get your feedback since  
>>> this would  probably mean that we'll have to modify the widget-
>>> form.xsd
>>>
>>> Thanks,
>>>
>>> Jacopo
>>>
>>>
>>> Jacopo Cappellato wrote:
>>>> David,
>>>> ok, I managed it (I'm using the ScreenFopPdfViewHandler).
>>>> FoFormRenderer is an implementation of the FormStringRenderer  
>>>> interface, exactly as the HtmlFormRenderer is an implementation  
>>>> of it.
>>>> So, HtmlFormRenderer is used to get an html representation of a  
>>>> form; FoFormRenderer is used to get a fo representation of a form.
>>>> The final goal is to get simple PDF reports directly from a  
>>>> screen and form definition.
>>>> Jacopo
>>>> David E. Jones wrote:
>>>>>
>>>>> On Aug 8, 2006, at 1:11 AM, Jacopo Cappellato wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm implementing a new FoFormRenderer class that implements  
>>>>>> the FormStringRenderer interface: the idea is to get fo  
>>>>>> representation of a form widget definition.
>>>>>>
>>>>>> I really hope to commit the very first version of this today,  
>>>>>> but I'd like to get some hints about where is the code (and  
>>>>>> what is the logic) that will instantiate the FoFormRenderer  
>>>>>> instead of FormStringRenderer class.
>>>>>>
>>>>>> Should I look at the view-map definition's "content-type"  
>>>>>> attribute in the controller file? If so, any hints about where  
>>>>>> I can find the code that handles this?
>>>>>
>>>>> It should probably be a new view-handler, ie a new class  
>>>>> mounted at the top of a controller.xml file and then used in  
>>>>> the view-map type.
>>>>>
>>>>> On a side note, what does the FoFormRenderer do differently  
>>>>> than the FormStringRenderer?
>>>>>
>>>>> -David
>>>
>