How much is that going to require you to have
public String getFoo() throws Exception;
on your interface?
Well, there will be some since JExcelAPI is in the habit of throwing
its own WriteException which extends Exception
but if you feel like it, we can drop the custom exception. But if
dropped, what should be done with
try {
// use PropetyUtils or something else that throws n exceptions
} catch (Exception e) {
throw new ExcelWorkbookException("really detailed message", e);
}
if we let the exceptions flow out, won't we lose the context, i.e.
can't tell the user in detail what went wrong? Or am I missing
something here (wouldn't be the first time)?
I just looked again at the code and see you are swallowing exceptions
-
don't ever do that ;-)
It's usually "not found"-handling but I'll look it over.
>> * We need to be careful in the documentation to always refer
to "the
>> Microsoft (R) Excel (R) spreadsheet application" (Microsoft (R) Excel(R)
>> doesn't cut it) - so I added &excel; and &Excel; macros to ensure we
do
>> this.
>
> OK. What about when referring to the file format? Should it be "The
> Microsoft(R) Excel() spreadsheet application file format" (I think
> it's actually called BIFF)?
Is it trademarked?
Probably. But OpenOffice isn't that careful about the usage (or Excel
references for that matter ):
http://sc.openoffice.org/excelfileformat.pdf
That's a good point - all your examples show using the value
attribute
explictly, but does it work with just text as the child (implied as the
value)?
I haven't written any code for it so it would be strange if it would
automagically work ;-)
Yup, this is definitely the hardest part. But I think it is worth it.
To me,
what these JSF control sets (mail, pdf, excel and html) provide is unified
way to create disparate types of output - so the idea is not just to mirror
the Java API in XML (which is already easier) but to also make it a
"seamless" experience. This is what I tried to do with mail - not just
mirror the API (which would have been super ugly anyway as JavaMail is a
pig), but to allow the user to write standard-JSF-like code but produce
mail.
How about investigating
http://www.w3.org/Style/CSS/SAC/ - apparently it can
parse standard CSS and allows you define your own selectors.
OK, I'll look into it. I think it would be a good idea to support
both tag attributes and css for layout.
The tag -> JExcelAPI factories use the attributes anyway so we could
parse the css and populate
the attributes (css overriding attribute or vice versa) so the
factories remain unchanged.
---
Nik