> -----Original Message----- > From: Steven Noels [mailto:[EMAIL PROTECTED]] > Sent: woensdag 12 december 2001 9:45 > To: [EMAIL PROTECTED] > Subject: RE: [RT] Managing Flow and Resources > > > -----Original Message----- > > From: Tom Klaasen (TeleRelay) [mailto:[EMAIL PROTECTED]] > > Sent: dinsdag 11 december 2001 10:08 > > To: [EMAIL PROTECTED] > > 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 > 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 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 ;) tomK --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
