> Piroumian, Konstantin wrote: > > <snip/> > > >>I'd be more happy if I can describe the flow in a "normal" programming > >>language, where I can express complex flow by writing a program. This > >>is what I'm trying to do in the Schecoon sub-project. Using the Scheme > >>language, and the fact that continuations are first class objects in > >>it, I want to implement the ideas described in the resources I > >>mentioned earlier. But the language to describe the flow will not be > >>Scheme, but one with a more familiar syntax. > >> > > > > Maybe Java? ;) > > Why not use EJB (Session Beans) or something similar to them (e.g. custom > > Avalon components) to control the flow? You can implement *anything* you > > want in Java. The reason that we don't use Session Beans as-is, is that it > > would have a lot of similar code. > > Careful here. You have to use the right tool for the right job. If you > were to propose EJBs as a flow control layer for a webapp, most veterans > would think you are nuts. You should never force a transaction to occur > over the wire simply to find out where to go next.
Agree. In our case the EJB layer is not for only controlling the flow, it also hides the business logic needed to make the decision on where to go next and also it interacts with the Workflow engine. Another requirement to our system was that the user should have persistent states - you can logout/timeout or even the web server can crush but you won't lose your data and next time you'll b back to your last state/screen. Also if you have to perform more than one business operation over the wire to find out where to go next, then you'll see that sending just an Event to flow controller is much effective - all the logic calls would be performed on the EJB layer and you'll get the result containing the current state with params. The only transaction over the wire would be sendEvent() call. Maybe our case is too specific to be taken into account, but it has quite good SoC: the presentation layer knows only how to display different states and how to translate requests into Events to flow controller. And knows nothing about the business logic behind the flow controller. > > As to using a "Component" to do the work, we already have the proper > granularity. I.e. Schecoon. Currently we have Actions to help control > flow, and we have Matchers and Selectors. Yes, that's true. We've been using actions to interact with the flow controller. So, why do we need another language to describe the flow? Why not Java? It will only make Cocoon more frightening to new people. I'm not a newbie in Cocoon, but even I am tired of revolutionary changes in it (C1 - C2 - .. - [C2 + Schecoon - Actions]), lack of documentation, etc. and it's going to be very hard to convience other people even to try it. > > Schecoon was started as they do not represent intuitive and useful > control layers for a webapp. That is why the Avalon Component thing > isn't going forward any farther than it already has. Do you think that Schecoon is more intuitive? It's just another programming language. >EJBs are for macro > scale transactions that you perform on your system. You use them when > you determine you have a need for them. You do not have a need for them > if all you want to do is control flow from one page to the next. This is true only for simple cases. What if you need a distributed flow control, persistent flow state, multiple applications using the same flow and everything interacting with a WFMS? Our implementation uses interfaces and is wrapped into web-server-side APIs (base actions and helper classes), so you never knows where is your controlling level implemented: is it an EJB or a Cocoon component or simply an object in users session. > > > > Our flow syntax is quite simple, but powerful and it's possible to describe > > most of the flow logic with it (the rest can be processed using custom > > operations that are implemented in pure Java). And another goog thing is > > that the flow language is XML and thus a visual editor can be written quite > > easily. > > :/ > > Keep in mind who is writing the code. Not all programmers trust visual > editors. I for one judge them guilty of writing poor code until they > are proven innocent (opposite of American justice, but using them has > made me a cynic). Again agree, but we also had such requirement: the screen flow and forms on the screens should be configured without need to program anything, e.g. using a special visual tool. All the logic is implemented in business components (they are also session and entity beans) and the flow can call their API methods to perform it's logic. If something needs to be programed then it must be done on the business layer. > > Also, the full Java language is too difficult to express in a simple > script environment. What about using JavaScript? You only have to > support certain models, and many web programmers are familiar with it. > Can JS provide means to call business logic from it? Simple cases are easily expressed in XML-based script. (I would send you a real sample, but it's prohibited in our company). > All we need to do is provide a bridge for Scheme continuations to the > JavaScript interpreter engine.... I'm not familiar with continuations, will look at them when there will be a sample for Scheme. > > > > I've been also thinking about adding extension mechanism (something like > > transformers/logicsheets) that would allow to add custom handlers to our > > flow script and an idea came to me: maybe flow controll can be plugged to > > Cocoon using sitemap logicsheets? In that case nothing is changed in Cocoon > > core and everybody can have the flow controller he needs/likes. > > > > Just my <i18n:currency value="0.02" /> > > We currently have the ability to choose our Sitemap implemenation > directly. Whether we choose the original sitemap layout, or we mount a > flowmap directly in its place doesn't matter. All that matters is that > requests go in and responses go out. I would like to have a possibility to choose the flowmap implementation and not the whole sitemap. Current sitemap is quite good for me to implement anything I need and the only thing to improve is action/action-sets and cleanup/stabilize the syntax. This is my opinion. Konstantin > > > -- > > "They that give up essential liberty to obtain a little temporary safety > deserve neither liberty nor safety." > - Benjamin Franklin > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
