cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: [RT] Managing Flow and Resources
Date Tue, 11 Dec 2001 13:39:45 GMT

> -----Original Message-----
> From: Tom Klaasen (TeleRelay) []
> Sent: Tuesday, December 11, 2001 10:08 AM
> To:
> Subject: RE: [RT] Managing Flow and Resources 

[big fat snip]

> However, XML allows you to enforce some limitations on the users. Java
> does not. As you can already see in the example above IMHO, 
> it gets very
> difficult to cling to and enforce the SOC principle. The 
> shopping-cart()
> function seems to be flow control, but the change-address() is already
> business logic IMO.
> Of course, the very intelligent programmers who are 
> developing this from
> the start, will be able to enforce the SOC for themselves, 
> but newcomers
> who learn by trial-and-error (as we all do) will have serious
> difficulties to grasp it, even if they want to.

Very right indeed. I'm currently working on a cocoon-based project where the
original developers also didn't realize the importance of separating
publishing, flow and business logic. For example, the business logic is
partly in the publishing pipeline, which has as a consequence that certain
flow decession can only be made in an xsl that generates html to redirect to
another page (ugly!) and more such stuff. Also some of the business logic is
in xsp's, which is very annoying because it's not possible to extend one xsp
from another, and it's quite difficult to do unit testing of them.

Looks to me that a struts-like thing where you replace the jsp part by
cocoon-pipelines would be the way to go (if you want to work xml based).

> Me too (is this
> English?) had serious difficulties to grasp the SOC in Struts 
> eg, and I
> even thought there wasn't one for quite a while. But then again, maybe
> that says more about my capabilities than anything ;-) 
> Anyway, Struts is
> also based mainly on java-code, and genericity and SOC is very hard to
> achieve.
> On the other hand, XML indeed isn't developed for logic. So maybe we
> should start on an limititions-enforcable programming 
> language LEPL ;-)

For business logic, I find java quite a good language, no need for a LEPL
for me :)

> > What we could do to support user adoption is 
> > provide plenty of
> > already implemented functions, and perhaps maybe later a 
> > Visio-like GUI to
> > draw the flow.
> If you're into Cocoon, you don't like GUI development (except maybe
> Bruno Dumon ;-)). It is a whole different world. So the 
> chances are slim
> there will stand up anybody to make a GUI.

GUI development isn't that different from webapp development. It's all based
around MVC (model-view-controller), or in cocoon speek MVC = "business
logic" - "publishing pipeline" - "flow". The fun part in gui development is
when you actually write your own rendering code (the view), instead of
reusing existing widgets.

Bruno Dumon

To unsubscribe, e-mail:
For additional commands, email:

View raw message