On Thursday 16 September 2004 15:19, Claudius Spellmann wrote: > >> Is it actually possible to use Java instead of Javascript in > >> flowscript ? > >> > > Ok, but which scipting languages are implemented in cocoon ? As far as I > can see only Javascript is available.
The javaflow block uses compiled java as a script, however I never got it to work the way I wanted it to work. The 'interpreter' rewrites the class file to basically make it an interpreter for its own bytecode. This means the class file will be loaded by a separate classloader that has the default class loader as its parent. This will prevent you from having circular dependencies between the flow and your business logic. For example a flow that calls some extra logic that will return the next flow to be started. If you intend to only use simple flows with limited business logic and no dynamic class loading, it should be fine. However it was insufficient for the project I am working on. I also didn't want to use Javascript, because of it's weak type system, so I ended up writing my own 'interpreter' -- or better flow-engine. This engine uses compiled classes and runs a flow inside its own thread. This approach has several advantages but also some problems: Advantages: - Exceptions are thrown to notify the flow in case of an important event (like a session timeout). This can also be implemented with a listener, however the lifecycle of a flow ends with a session timeout, so an exception seemed more logical. - It's a more 'natural' look at a flow. - The flow itself runs at native speed. Disadvantages: - Every session will need its own thread. This can increase the load of a server quite a lot, allthough I haven't stressed it enough to be sure. The threads are locked when idle, so they should not use any cpu time. - It is not possible to return to a previous continuation. There is no way to capture the stack of a thread. You need this to restore a previous continuation. - It seems as the cocoon framework is not entirely thread safe. The session context seems to depend on the thread that is running. Even when the interpreter is locked during execution of the flow and vice versa, the context changes when entering the flow. I had to use reflection to make the interpreter thread call methods that would otherwise have been called by the flow itself. Unfortunately I currently cannot release the code of this flow engine, because it's written for the company I work for. However this company is investigating open source and is planning to release (atleast parts of) the source under an open source license. I myself am still hoping I can contribute to the Cocoon project by making this flow engine available. If you can't wait for this, you can check the current implementations of the Interpreter interface. Currently there are several implementations: FOM_JavaScriptInterpreter, CompilingInterpreter, ApplesProcessor, AO_FOM_JavaScriptInterpreter, JavaInterpreter Good luck, Emond Papegaaij --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
