[seam-dev] Excel module added to SVN

[Nicklas Karlsson]

> 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