cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Conover <scono...@groundswell.net>
Subject RE: Design of web apps based on Cocoon
Date Sun, 10 Sep 2000 04:33:04 GMT
> database --> ESQL --> XSP --> XSL --> result

Aren't esql and xsp in the same layer?  esql is just a taglib and gets
thrown in with all the other xsp stuff, i.e. you don't get the results of
your esql queries at the xsp stage, rather that's the stage where you're
defining those queries.

I'm not using EJB with cocoon but could easily be doing so in the future,
and I was wonder the same thing as you.  i.e. should the session beans have
toXML() methods that produce the content part?  Of course, it's not like
your session beans are initialing the processing (a web page request is), so
you'd have to request the session bean to do something in the xsp
layer...maybe that makes sense too, because the source files are sort of a
static declaration of the content that will exist in your page.  The xsp
looks at that "declaration" and makes the proper call(s) to session beans,
just like what happens with SQL stuff.

Actually I've kinda honed in on wht I think is a good interpretation of mvc
as it applies to xsp.  

content (xml) --> xsp/sql --> sql results cleanup (xsl) --> controller (xsl)
--> view (xsl)

It takes 3 steps to get the "model" right, then the controller interprets
the model (creates the view).  It seems to me that, the way xml/xsl works,
letting the controller build the view is not much different than having the
controller grab a pre-built view and supply the model to it.  In the XSP
layer I do all the stuff that Java is good for (or at least in my app's
context): grab session and request variables, do authentication, build the
sql queries and perform updates and inserts.

For a while I didn't have what I now call my controller layer in there, and
putting it in bumped up my average processing times by 100- 150 ms, but
that's not a big deal for me, and who doesn't mind paying a small performace
cost for cleaner code (not me!).  I've refactored and recfactored and I
think I've come upon a good XSP interpretation of proper MVC.

Comments/critique welcome!

Regards,
Steve

> 
> My assumption was that I'd put any business logic I'd need 
> into XSP (and
> perhaps into clever SQL queries) and perform output 
> formatting with XSL. It
> worked for me, but then, I didn't try anything really complicated.
> 
> However, some of the recent emails here suggested that EJBs 
> should be used
> at the beginning of the above path, encapsulating SQL-queries 
> and BL, while
> XSP would be only used to select what actually gets passed to 
> formatters.
> Another suggestion was to avoid creating producers by hand.
> 
> 
> My question is: could someone shed some light into overall design of
> Cocoon-based apps? I mean, what's the preferred path to use, 
> starting from
> records in the database up to formatting stage, assuming that 
> there is some
> BL and some formatting?
> 
> 
> Thank you in advance,
> Milek
> -- 
> mailto:thorgal@amiga.com.pl   |  "Man in the Moon and other 
> weird things" -
> http://wfmh.org.pl/~thorgal/  |  see it at 
> http://wfmh.org.pl/~thorgal/Moon/
>          Fight for the good cause: http://www.laubzega.com/dvd/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
> 

Mime
View raw message