Hi!
Hunsberger, Peter wrote: [snip]Go back to last Novembers discussions on this issue. We went through[snip]
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).
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.
