cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Klaasen (TeleRelay)" <>
Subject RE: [RT] Managing Flow and Resources
Date Wed, 12 Dec 2001 10:00:46 GMT
> -----Original Message-----
> From: Steven Noels [] 
> Sent: woensdag 12 december 2001 9:45
> To:
> Subject: RE: [RT] Managing Flow and Resources 
> > -----Original Message-----
> > From: Tom Klaasen (TeleRelay) []
> > Sent: dinsdag 11 december 2001 10:08
> > To:
> > Subject: RE: [RT] Managing Flow and Resources
> What an amusing gathering of ex-collaegues :-)
> > 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.
> True, if and when there's some XML Schema or Schematron 
> validation in-place.
> Nothing which couldn't be done by an Scheme interpreter, I guess ;-)

Let's add some more languages to Cocoon, so that nobody knows all
languages anymore, and developing on Cocoon _requires_ teams of 3 or 4
people. And let's then try to roll Cocoon in into a company. 
Not that I have something against Scheme in itself. But that was another
thread, I thought.

> Semantical validation isn't something which is supported very 
> well in XML,
> Schematron being a (difficult) exception.
> > 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. 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.
> I agree with Tom that SoC enforcement should be done 
> programmatically and not
> by documenting best practices or hoping that developers will stick to
> guidelines.

Nice summary.
> > 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.
> If we want to force flowmap-designers to stay away from the 
> SoC-alarmzone, a
> visual tool that generates Soc-compliant code is much better 
> than the ultimate
> freedom of a textfile with ECMAScript, Scheme or XML 
> markup... using such a
> GUI would force you to design the flow and gives you little 
> opportunity to
> mess with the syntax of the flowmap

I agree that having a decent GUI would facilitate things a lot. But I'm
only suspicious as who is going to develop such a GUI. I've seen things
happening on ant-dev eg, where they were going to develop a GUI, and it
didn't go smooth to say the least.
> thinking about it... what about UML...? considering a flowmap 
> to be something
> like an activity diagram?

State diagrams should do the trick. This reminds me of the proposal of
Diana (was it?) some weeks ago. She was working on a flowmap-like thing,
and had it almost right imho, but was struggling with the syntax. I was
hoping to hear more of her, but she seems to have disappeared?
Anyway, UML: still have to find a decent 'free' UML tool. Nobody's going
to use C2 if they have to pay $$$ for Rose or TogetherJ, just to be able
to draw state diagrams. Not a very academic approach to the problem
though ;)

> Regards,
> Steven Noels
> (+32)478 292900
> ps: (Tom) this flowmap-approach reminds me of the idea of sticking a
> rules-based engine inside Maven as a central switching board

Me not, to be honest :P I saw the switching board was more like the
sitemap... but that's stuff for a private conversation, since our
ex-collagues have already taken out too much dirty laundry ;)


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

View raw message