[seam-dev] Excel module added to SVN

[Pete Muir]

On 6 Aug 2008, at 07:16, Nicklas Karlsson wrote:

>> 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)?

No you are right, there is a good arguement for wrapping it to.

>
>> 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

I think then "the BIFF(R) file format" should be fine. Lets just be  
careful.

>
>
>> 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 ;-)

Should do ;-) Look at the mail example for how.

>
>
>> 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
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev