TR : RE : [Springframework-developer] View technologies

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

Hello everybody,

As in my last message, it was not clear that I have added comments
inside Rod's part, I send it again, but without olds included messages.

Regards,
Jean-Pierre Pawlak


When we will reach the 0.8 stage, will be it from interest to contact
sites like http://www.waferproject.org 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.