cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Noels" <stev...@outerthought.org>
Subject RE: [RT] Managing Flow and Resources
Date Wed, 12 Dec 2001 08:44:48 GMT
> -----Original Message-----
> From: Tom Klaasen (TeleRelay) [mailto:tr-tklaasen@telerelay.com]
> Sent: dinsdag 11 december 2001 10:08
> To: cocoon-dev@xml.apache.org
> 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 ;-)

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.

> 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

thinking about it... what about UML...? considering a flowmap to be something
like an activity diagram?

Regards,

Steven Noels
http://outerthought.org/
(+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


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message