cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: xml languages
Date Thu, 20 Jan 2005 21:22:23 GMT
Peter Hunsberger wrote:
> On Thu, 20 Jan 2005 20:58:51 +0100, Daniel Fagerstrom
> <> wrote:
> <snip>existing generator/transformer approaches</snip>
>>>What many people seem to want is a template language other than XSLT.
>>>Personally, I agree that that seems to be re-inventing the wheel, but
>>>open source communities seem to like constant mutant evolution...
>>The problem with using XSLT as template language is that it is hard to
>>get pull access to Java beans. You can of course serialize your Java
>>object to SAX with e.g. Castor or Betwixt in a generator or a source.
>>But that soon becomes expensive if you just want to access a little data
>>from a large Java object.
> If you're working with a legacy system I can see this.  If you're
> starting from scratch I think this shouldn't be a real issue: don't
> write large Java objects or make sure that they are used in their
> entirety.

The small or large Java objects often are connected to each other in a 
graph or a tree e.g. So you have to write some directives for Castor etc 
about what part of the graph you want to serialize.

> For us, there's a pretty close mapping between the database layer and
> what we want to see as raw XML. Our approach, is basically
>     EJB -> proxy -> datasource -> generator -> XSLT
> where the datasource is looked up using a factory pattern against the
> database for a generic generator.  The datasource handles the
> conversion of the data classes handed off from the EJB layer to XML
> but all of our beans are designed from the get go to map to the front
> end requirements.

It might be an excelent solution in some cases but for the moment I'm 
more interested in contributing to making simple things simple in Cocoon 
than in making complicated things possible (which they allready are).

So I think it is nice to be able to do "the simplest thing that could 
possibly work" like:

JavaBean -> JXTG -> HTMLSerializer

whithout having to think about what enterprise patterns I would like to 
use today, teach my colleague about them and about how to use Castor, 
how to write beans that fits the frontend, how to use XSLT etc, and 
trying to understand what it does a couple of months later.

Of course in many cases you need more complex approaches but quite 
often, YAGNI.


View raw message