Hi Konstantin, On Thu, 11 Apr 2002 14:58:39 +0400, Piroumian Konstantin <[EMAIL PROTECTED]> wrote:
> > From: Ovidiu Predescu [mailto:[EMAIL PROTECTED]] > > On Wed, 10 Apr 2002 20:54:19 -0500, "Ivelin Ivanov" > > <[EMAIL PROTECTED]> wrote: > > > > > I'll keep asking dummy questions until I start to get the > > picture or you > > > stop responding ;) > > > > Please keep asking if you see I don't respond ;-) There was a lot of > > traffic these days on the mailing list, and I know I forgot to answer > > to few messages I wanted to. > > Would you mind if I join to Ivelin in asking ...say, questions that are > easy for you to answer? ;) Sure ;-) > > The idea is that since the flow control is a full programming > > language, you can do pretty much everything in it. > > Let me ask a question? Would you need to do "pretty much everything" in a > flow controller? IMO, flow controller has well defined and limited task: > move from state to state and select appropriate "view" (page in your case) > depending on the data model for this flow and current request. So, I can > seem a little importunate, but your sample can be easily rewritten like > this: > > <flow> > <variables> > <variable name="instance" type="xml" /> > </variables> > <operations> > <operation name="getUserResponse" class="my.GetUserResponse" > /> > </operations> > <state id="firstpage"> > <on-enter> > <!-- initialize the $instance variable --> > <!-- send response to caller, e.g. the sitemap --> > </on-enter> > <on-event name="next"> > <exec operation="getUserResponse"> > <set-result var="$instance" /> > </exec> > <choose> > <when test="XPath($instance, > '/customer/hasCar')"> > <goto state="second" /> > </when> > <otherwise> > <goto state="third" /> > </otherwise> > </choose> > </on-event> > </state> > > <state id="firstpage"> > ... > </state> > > <state id="firstpage"> > ... > </state> > ... > </flow> > > So, this is the XML version of the same thing. A little verbose for > handwriting, but much better for a Visual Flow tool creation. What do you > think? What can procedural approach do more than this? Continuations can be > handled by the engine itself (which in turn can be implemented in Rhino's > JavaScript, Scheme or something else). My opinion is that this approach is restrictive compared to a programming language. And too verbose. I may want to place common behavior which is repeated across multiple <state>s in a function. I may need to do small things which the designer of XML language syntax didn't think about. Even with a way to extend the XML language, I would need to write Java code to do it, I need to recompile the whole bloody thing, debug it and remove all the inherent bugs. That's too much of a price to pay when an interpreted language already does it for me. I can even prototype the whole application in the interpreted language if I want, and move it to Java when it works satisfactory. I cannot do this with an XML syntax underneath, at least not without major pains. Also we're not in the business of writing Visual Flow tools. Perhaps a big company might capitalize on the "everything XML" hype and come up with lots of tools to make your life easier. But the tools need to be modified if the syntax of the language is changed by the addition of a small feature. My notion of easy life is if I can do it with Xemacs ;-) I guess most people would like to use their favorite editor to write code. > > As you notice the flow control is acting the Controller in the > > Model-View-Controller paradigm (MVC). The Model is the business logic > > behind, and the View is invoked using sendPage(). > > > > The above sendPage() is actually a simplification, what you pass to it > > is not only the URL to be interpreted by the sitemap, but also an > > object, an array of a dictionary containing information to be placed > > into the generated output by the View, e.g. by the generator in the > > matching pipeline. In this model, the generator no longer needs to do > > any business logic, it just extracts the data from the object passed > > to it. The jpath.xsl logicsheet does this for XSP, but this was only a > > quick way to implement it. In the near future I'll come up with a > > simple transformer which could be placed in the pipeline, that does > > the same thing. > > > > The above MVC programming model will render obsolete XSP and all the > > other page centric approaches to Web programming. The MVC model I > > propose will introduce a very clear separation between the layers of a > > Web application. > > And this is very similar to the approach we've used in our Screen Flow > Controller and it uses XML script and someday we'll develop a GUI tool for > it, just like the one which is used in WebLogic Process Integrator! ;) The MVC approach is very nice indeed. My experience however with writing all these tools is that it takes a lot of time, energy and people to develop and maintain them. All this can be focused on other things, which bring a lot more value. And how do you recoup all the money you invested in this? You certainly cannot give away this whole thing for free, can you? How easy will be Cocoon to program without these nice, fancy tools? Alternatives are always good, so you're free to donate your implementation to Cocoon. We can only benefit by having multiple ways to do it. Regards, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
