Torsten Curdt wrote:
>
> <snip/>
>
> > > > There are yet many doubts to cover from the flowscript stuff that start
> > > > talking about something else makes less sense ATM, IMHO.
> > >
> > > This is one of them.
> > > Flowmaps are so powerfull that all the stuff that was innapropriate to
> > > be done in the sitemap (heavy webapps) will automatically slip over to
> > > flowmaps.
> > > And since it's procedural, it's a *big* concern of mine that flowscript
> > > will become the problem-solver catchall.
> >
> > I hear you, but since we all agree that business logic shouldn't be in
> > the flowscript, I don't understand the need to discuss whether or not
> > it's good to have business logic defined in a scripting language.
> >
> > This is an entirely separate concern.
>
> ...they are not entirely separate since the business logic might also
> influence the flow. There should be a good separation (SoC) but I think we
> need to see the full picture. So I don't think it's totally useless to talk
> about it right now - but we shouldn't mix it up...
I'm wide open to suggestions on how you can *force* somebody to separate
its flow logic from its business logic.
Also, I'm wondering how you can make this 'forcing' be effective no
matter what the flow and business logic of somebody is.
My opinion is: let's keep the flowscript and let's keep it limited to
what we need today and be careful in adding more features in the future.
The rest will be done with docos about best practices, flow patterns and
guidelines.
Just like you can write crappy software in Java and great software in
Perl.
In media stat virtus.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
