Hi, Ovidiu! > From: Ovidiu Predescu [mailto:[EMAIL PROTECTED]] > 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 ;-)
Thanks ;) > > > > 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: <skipped /> > > 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. I can confirm that. But with a more or less stabilized DTD for XML script you can do a lot of things (we use it for all our wizard-like processes, like customer registration or service subscription/unsubsription that are quite straightforward). I admit, that for catalog navigation or other graph-like things XML syntax could be limiting and need extending. >That's too much of a price to pay when an interpreted > language already does it for me. The key phrase is "does it for me" - interpreted language is another language that you should learn, you should get used to it and you should study also a lot of "best practices" samples and good docs to learn from. >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. With XML syntax you'll be able to prototype the whole application using an intuitive visual tool and have Java to handle it. With XML syntax you can at least use compiled sitemap approach - use an XSLT to compile your XML scriplets into Java classes. > > 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. Agree. We had a requirement for the application flow to be configured without need to program it, that's why we've choosed XML format. > > 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. I also prefer to edit XML in XML Spy using text mode, but I know a lot of people that feel comfortable with its tree-view mode. > > > > 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? I work in a company that develops Billing & Customer Care systems for mobile operators and of course, our systems are too far away from being free ;). Maybe this also explains why I talk so much about visual tools and so on. > > 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. I would do it if I only could. Although I was the originator of the idea of our controller and its first implementer, but it's proprietary of the company and I'm also not sure that I'm allowed to share my thoughts on it her. One thing I am sure is that we all benefit from this discussion. I just only want to say, that I need to have a possibilty to plug-in any flow implementation to Cocoon I like. Maybe even to have different solutions concurrently. Thanks for your time. Regards, Konstantin > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
