One more point...The logic for reading the template
doesn't necessarily belong in DefaultHssfExportView.
It probably belongs in HssfTableWriter, which could
read the template, write its contents to the workbook
passed to it by the export view, and so on...But the
key point is that most of the real rendering work is
now done in the table writer, not the export view,
whose job is to set the content-type and write to the
output stream. This implies that the table writer
should become the extension point for exports, since
most of the time extensions just need to modify the
rendered content in whatever medium, not change the
mime type or how the data is written to the output
stream. For instance, I created an extension to
HssfTableWriter but had to create an ExportView whose
sole job was to use my new HssfTableWriter.
Otherwise, it was no different than
DefaultHssfExportView, which instead should have the
ability to wire in an HssfTableWriter.
Making the extension point the table writer would also
make it easier to modify how tables are rendered in
html, by extending HtmlTableWriter. Say you need to
add html table elements displaytag doesn't support out
of the box. Extend HtmlTableWriter, override the
appropriate method to write the elements you need, and
configure displaytag to use your new HtmlTableWriter
to render html.
-Jorge
--- Jorge Barroso <[EMAIL PROTECTED]> wrote:
> Template-based exports could be useful for
> boilerplate
> content, like a company letterhead, etc...
>
> Since these are Excel-specific config values,
> perhaps
> table tag attributes is not where they belong, but
> in
> excel-export-config properties, say
>
> export.excel.template="path/to/template.xls"
> export.excel.startRow=4
> export.excel.startColumn=3
>
> These could be set with the setProperty tag or in
> the
> props file and made available to the excel through
> TableProperties, which is obtained from TableModel.
>
> DefaultHssfExportView could then open the template
> workbook if one's configured and pass it to
> HssfTableWriter, which would then need to change to
> no
> longer assume its workbook is empty, but look look
> for
> the configured startRow ans startColumn values.
>
> Someone also asked a while back about basing PDF
> exports on templates. Perhaps, it would be worth
> doing for PDF and RTF as well.
>
> -Jorge
>
> --- Karsten Voges <[EMAIL PROTECTED]> wrote:
>
> > Hi all,
> > I am thinking about enhancing the Excel/POI export
> > functionality to
> > use templates.
> > Has anyone done something like this?
> > My usage point would be this:
> > <display:table id="row" name="${test}"
> export="true"
> > excelTemplate="path/to/template.xls" startRow="4"
> > startColumn="3" />
> >
> > Is there a possibility to get this properties? The
> > TableProperties,
> > which are included in the TableModel only keep
> track
> > of properties
> > declared in files, or am I missing something here?
> > Or can the TableModel hold the information itself?
> >
> > Because if I could retrieve this information from
> > the TableModel or
> > similar this would be easy to implement.
> > Anyone else interested?
> >
> > Cheers,
> > Karsten.
> >
> >
> > _______________________________________________
> > displaytag-devel mailing list
> > displaytag-devel@lists.sourceforge.net
> >
>
https://lists.sourceforge.net/lists/listinfo/displaytag-devel
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
displaytag-devel mailing list
displaytag-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/displaytag-devel
