cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: XMLForm & JSF
Date Tue, 08 Apr 2003 20:19:29 GMT
Bruno Dumon <bruno@outerthought.org> wrote:

> On Tue, 2003-04-08 at 21:24, Hunsberger, Peter wrote:
> > Bruno Dumon <bruno@outerthought.org> asked:
> > 
> > > > be plugged in as well as any other validator.  However, 
> you really
> > > > don't want to marshal the data to the bean and then 
> unmarshal to 
> > > > XML/SAX just to run the validator?
> 
> Basically, yes.
> 
> Though:
> 
>  * I don't want to code that manually each time, and I don't 
> want to write a bean just for that purpose, but let a 
> framework do all this work based on a configuration file.

Yes.
 
>  * and in case the validation is succesful, I don't need to 
> stream back to SAX, but then I already have a strongly-typed 
> data structure which can be used right away by other Java code.

True, if your target is more Java code, which it certainly is for most
(99.999%) current cases.

>  * performance-wise, it's certainly not any worse than 
> marshalling it to a DOM-tree.

Yes, very true, we need to get rid of that.

>  * and I have a general preference for doing this kind of 
> coding in Java. But maybe I haven't seen the light yet, so 
> I'm keeping an eye on the alternative approaches.

We'll keep on praying for you brother.... ;-)

> 
> >  I think you really want
> > > to have the
> > > > capability to run validation directly on the SAX stream
> > > before it gets
> > > > marshaled into any model?
> > > 
> > > Slightly confused now: where are you currently doing
> > > validation? In the Cocoon-SAX-pipeline itself?
> >   
> > In our current code we go from SAX to DOM in an action 
> handler (it's 
> > "legacy" code plugged into Cocoon).  That's obviously bad, 
> one way to 
> > fix it would be to use a generator/transformer on the back 
> side of the 
> > POST and have a serializer do the side effect of updating the 
> > database, but I'm not sure I like that any better.
> 
> Hmmm, sounds a lot like Daniel Fagerstrom's input pipeline idea.
 
Perhaps so, though I think he was looking for even more capabilities than we
where, updates to the database can be a simple side effect in our case,
where as I believe he was looking to be able to completely separate the two
processes?  If we had his capabilities that would work also.  I've got
another slightly similar problem where I've got to generate two output
streams and I'd love to have some Cocoon best practices (relative to the 2.1
code base I guess) for this, to date I'm not sure if there is a consensus?

Mime
View raw message