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
