Hi Keith,
Thank you for the detailed description of your needs, to sum up, you
preffer a 100% java approach
because filling a template seems to be like using dynamite to kill flies.
I agree with you that "sheet.getRow(1).getCurrentStyle().setBold(true);"
is a clean solution too,
easy style handling and creation is something planned for the new releases.
Playing with styles is not as simple as you could think because styles
are shared, hierachical, dependent of installed fonts etc...
that's why we always use OpenOffice for such tasks.
The main idea of the API is something like MVC, we separate content and
form.
Content being handled and maintained in java ; form being manipulated
with OpenOffice.
We provide methods to modify the strucuture of the sheet
(add/insert/... rows and columns).
Look at org.jopendocument.dom.spreadsheet.Table , the method "merge"
uses a TableModel
which is what you are looking for easily inject your data.
http://www.jopendocument.org/start_spreadsheet_2.html seems, for us,
easier than doing all the dark stuffs in java
and far more performant. Will you be happy to modify and deploy a new
version of your application if users preffer red titles instead of bold?
Regards,
Guillaume
Guillaume:
Thank you for your comments. The "freeze" "feature" helps me
understand the boundary between the ODF spec and the OOo app. Thanks
for the clarification although I'm not sure why the distinction was
made at this level. I guess it falls in the same category as why
formulas are not part of the ODF Spec (according to my very limited
understanding--case in point why MS doesn't handle formulas in their
ODF implementation in the upcoming MS Office service pack). Again,
not to start a discussion here on the merits of the decision, it just
doesn't seem intuitive to me why that decision was made (or not made
as the case might be).
On the question of why I would prefer to create the styles
programmaticaly: similarly to the above question is the
intuitiviness. Being dependent on external files in an enclosed
application for a singular purpose simply adds more mud to the
application. Managable, yes. But from my perspective, I would prefer
fewer file dependancies than more.
Here is my situation. Maybe this will help everyone understand how
this library might be being used in the real world.
I work for a small custom manufacturor of plastic goods. We have
about 125 total employees in the whole organization. I manage the
computer systems for this company with help from one other person, my
network administrator. I am the sole developer of any software. My
primary role in developing software is to provide my users the ability
to extract pertainate data from our ERP system in a form that allows
them to view and anaylse the current state of inventory and other
company information. My primary means of providing this information
is SQL queries which are built into a custom shell with filter
parameters that the user provides at the time of run. My result,
presently, is written to a *.csv file, which I pass as a parameter to
scalc.exe to open. This works very well. The primary concern that I
have is that I don't have the ability through this mechinism to
provide a view-ready spreadsheet. By view-ready I mean that the end
user must do all formating him/her-self. Also there is not an easy
way to time-stamp or describe the resultset in the file--so the user
must provide that info him/her-self. (I. E. what query was ran, when
was the data extracted, what were the parameters for the query, who
ran the query) This info would be placed on the default page layout
so that if the user decided to print the data, the context would be
provided as part of the report. (I also am planning on placing this
info in the metadata of the ODS.) Pushing this info to the ODS would
be the second step in development for this project after first just
creating an ODS and then getting the basic formating down.
I envision a single static class with a small number of method calls
where I pass the pertinet resultset, parameter list, user info, ect
and the class builds the ODS and launches OOo with the new ODS
passed. I defininly can (and will if need be) use a template file for
the resulting ODS, but again, it seems that it would be intuitive to
have that capability programmatically. Something similar to:
sheet.getRow(1).getCurrentStyle().setBold(true);
You said: "A template is by nature done by humans that always preffers
a GUI. It reminds me why MS Office won over LateX ;)" . Are you
thinking maybe a complex form or template such as an Invoice or
something that might actually be a document of some sort? In that
case, I fully agree, a template is most definetely the better way to
go. Logos change and other items might change. Providing the data to
a template in this scenerio would definely be easier than the way I'm
doing my stuff. But I'm only providing minimum formating (bolding the
first row, for the user's convenience, and freezing that row). Then
providing as described above the parameters ect for context.
Hope this helps.
Keith
