cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Less is More, Finite State Machines and Balkanization
Date Tue, 15 Jul 2003 18:49:27 GMT
On Tuesday, Jul 15, 2003, at 01:13 America/Guayaquil, Andreas 
Hochsteger wrote:

> Hi!
>
> Hunsberger, Peter wrote:
> [snip]
>> Go back to last Novembers discussions on this issue.  We went through
>> this entire issue at that time. At that point Stephano felt the hooks 
>> we
>> needed would probably end up in Cocoon. It's not so clear that they 
>> will
>> anymore, or if they do that the semantics will be very generalized.  
>> I'm
>> not asking for additional core services.  I'm (more-or-less) asking 
>> for
>> ways to treat flow as a generalized component.
>> I'm not asking anyone to change the way JavaScript flow works, I'm 
>> just
>> supporting Sylvain and Marc's position that there should be ways to 
>> hook
>> other alternatives in and providing an existing use case that
>> demonstrates there are other alternatives (lest anyone think that they
>> are the only ones with the need).
> [snip]
>
> I totally agree with you.
>
> Consider another use case:
> A big company uses expert systems with big knowledge bases to drive
> their business.
> How could you use the "rules" which are already defined there to affect
> the workflow of your Cocoon application?
>
> I hope all agree, that translating them to JavaScript (as often
> suggested) is not a good option ;-)

Wait a second. I never suggested to translate them into javascript, I 
just suggested to do something like

  function handleTransition(state) {
     var fsm = cocoon.getComponent("FSM"); // here you get your legacy 
code
     sendPage(fsm.getNextState(state)); // here you use it
  }

Tell me: is this *so* unreasonable?

I think it would be even much less work than to implement a wrapper 
extending the provided abstract flow-hook interfaces.

True, there is some speed overhead due to the rhino interpretation 
phase, but for rad prototyping, the above approach works great even for 
legacy stuff.

--
Stefano.


Mime
View raw message