RE : [Springframework-developer] View technologies

[JP PAWLAK\(Tiscali\) <jp....@ti...>]

When we will reach the 0.8 stage, will be it from interest to contact
sites like http://www.waferproject.org/index.html to be registered?
=20

> -----Message d'origine-----
> De=A0: spr...@li...
> [mailto:spr...@li...] De la
part
> de Rod Johnson
> Envoy=E9=A0: jeudi 8 mai 2003 09:40
> =C0=A0: j=FCrgen h=F6ller [werk3AT]; Spring Developers (E-mail)
> Objet=A0: Re: [Springframework-developer] View technologies
>=20
> I'll put iText back.
>=20
> JP, do you want to contribute POI view? As you've been
interested/involved
> in this project since before we went to SourceForge, I'm happy to give
you
> commit access if you are likely to make ongoing contributions.

(JPP)=20
Yes, I will be happy also. I'm not focusing on a particular part of the
framework, but writing what I need for my applications and not being
currently available. Just tell me about the commit policy for the
changes, will I have to ask someone before committing changes?

Concerning the POI view, I will clean the documentation and have some
minor changes to make in order to use the Spring localisation. I have
forgotten to say that the Excel template can be a set of localised
templates.

I have also in the pocket a useful helper for paged tabular data. It is
not an all cases wizard, but for not huge collections it is very useful.
Letting the class in the user session and putting it in the view model,
it provides the possibility of page changes, sorting, filtering and
providing all information like number of pages/records, current page and
so on. It is not bound to a particular view technology or framework
(could so good be used in Struts). It can be a general use as it uses a
callback method for retrieving the data to populate when necessary the
collection to display. Therefore, it need to be maintained (ie in the
user session) and contains the whole collection to display, not only the
data to display on the current page.

>=20
> I would really like to have some form of XML/XSLT support, so I might
> refactor the old one to remove the present conversion library and
leave it
> an abstract class. The developer would need to subclass it to generate
the
> actual XML from the model, using Castor or whatever. Does this sound
> reasonable?

(JPP)
Living without XML will be difficult. Your proposal seems to be clean.
But another point to this: for an effective use, it is useful to chain
two XSLT transformations. The first having to create a cohesive XML from
the template and the view model, the second for making the rendering.
I dream also of a bridge to Cocoon.

>=20
> Let's leave XMLC for now. Maybe put in documentation that we can offer
> support, to let people ask for it if they want it.
>=20
> I've also written a simple JdbcBeanFactory that I'll add before 0.8.
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> So what do we think is outstanding between now and 0.8? Remember this
> isn't
> 1.0...
>=20
> As far as my work goes, I want to
> - put iText view back
> - remove Attrib4j dependency for now, as Attrib4j support isn't usable
yet
> and the properties tx interceptor format is the way to go for now
> - add JdbcBeanFactory
> - I was going to remove DynamicProxy and the ejb.access package, but
I'm
> not
> sure I have time to do this in the next few days. Might look at it
today
> if
> I get time.
>=20
> We will need some examples, and preferably a web site.
>=20
> Regards,
> Rod
>=20
>=20
> ----- Original Message -----
> From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> To: "Spring Developers (E-mail)"
> <spr...@li...>
> Sent: Thursday, May 08, 2003 8:14 AM
> Subject: RE: [Springframework-developer] View technologies
>=20
>=20
> JP and Rod,
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Regards,
> Juergen
>=20
>=20
> -----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
>=20
>=20
> JP,
>=20
> Good point.
>=20
> - 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.
>=20
> 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.
>=20
> - XMLC: I had no reason for testing it and don't like too much the
> approach.
>=20
> 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.
>=20
>=20
> -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.
>=20
> RJ - This depends on only one Jar. Maybe we should put it back in
Spring.
>=20
> -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.
>=20
> RJ - Could be useful to have this in Spring.
>=20
> I think we should put XML on the todo list, put PDF (iText) back in,
and
> add
> JP's Excel view.
>=20
> If there's agreement on this I'll add the PDF view shortly.
>=20
> Regards,
> Rod
>=20
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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
>=20
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
> -------------------------------------------------------
> 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
>=20
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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
>=20
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer