RE: [Springframework-developer] View technologies

[<jue...@we...>]

JP and Rod,

I'd also like to see the iText view back in Spring, and POI support =
sounds interesting too. I'm not too fond of XMLC personally, but I =
wouldn't mind including it in Spring too.

Regarding third-party dependencies: As this issue only affects =
developers if we separate the libraries during deployment, I don't =
consider it a problem at all. Such libraries don't change on a daily =
basis, so they only create overhead on initial checkout/update but not =
on consecutive updates. We shouldn't worry about them too much.

At least they are not redundant, like including numerous WARs and EARs =
in a distribution - containing the same libraries again and again. I =
mean the Struts/WebWork style, unnecessarily producing distributions =
larger than 20 MB. If we use a simpler approach for Spring =
distributions, even including all docs and tutorials, we will still not =
exceed the 10 MB threshold, probably clock in way below.

Apropos up-to-date libraries: We should probably care for newest JARs in =
our lib directory before 0.8, i.e. Log4J 1.2.8, Velocity 1.3.1 final, =
Clover 1.1.1. I volunteer to check these at the beginning of next week.

Regards,
Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Thursday, May 08, 2003 8:42 AM
To: JP PAWLAK(Tiscali); Spring Developers (E-mail)
Subject: Re: [Springframework-developer] View technologies


JP,

Good point.

- XML/XSLT: this one was not really a requested feature. The cyclic java
architecture, even in core objects, was really a problem (example: a
Locale has a defaultLocale property which is itself a Locale.). This
problem was noticed by Rod, but worked not as good as expected, the
source of the patched jar being not available and the original library
didn't be aware of this problem. My feel is that in real world a product
like Castor will certainly be better, even if it's more complex at the
beginning.

I agree. I think Castor is a better approach. However, I think having
support for transforms in Spring would be good: might have to put the =
onus
on the user to provide the doument.

- XMLC: I had no reason for testing it and don't like too much the
approach.

XMLC is amazingly fast and, while a bit weird, it has some things going =
for
it. Unfortunately the XmlcView brings in about 2 Mb of XMLC =
dependencies, so
it would be a real problem with third party libs. Although I guess that
affects only developers.


-PDF-iText: I had to render queries results in PDF format for friendly
printing and emailing the results as one clean document. I had no time
to search on others ways like FOP having in a sense a more attractive
approach. But iText was simple to learn and the result is good. The only
drawback is the servlet-style writing hand-coded presentation.

RJ - This depends on only one Jar. Maybe we should put it back in =
Spring.

-Excel-POI: It was not in Rod's book, but always the same data had to be
reworked by users, so an Excel document was a good choice. Having the
velocity and iText views source, it was simple to write an ExcelView
class using Jakarta's POI.  This class loads an Excel template (it can
also generate a blank document), completes it before serving. Also a
nice result. The same drawback as for iText can be addressed.

RJ - Could be useful to have this in Spring.

I think we should put XML on the todo list, put PDF (iText) back in, and =
add
JP's Excel view.

If there's agreement on this I'll add the PDF view shortly.

Regards,
Rod






-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer