On Fri, 12 Apr 2002 15:16:12 +0400, Piroumian Konstantin <[EMAIL PROTECTED]> wrote:
> >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. You'd be surprise to find out, but I started to look into JavaScript more seriously only 2 months ago. I don't think learning a new language is such a big thing. With an XML syntax you have a similar learning issue, plus you get frustrated each time you want to do something and the framework doesn't implement it yet. You pretty soon end up digging in the implementation, and try to add your own things into it. I have this experience from Anteater, the functional testing framework I wrote for Web apps and Web services on top of Ant. > >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. Again, I don't believe in compiling things on the fly using XSLT. Doing compilation in XSLT is pretty lame, and very soon you end up maintaining a lot of code. I'm not even touching optimization techniques to generate better code, it's almost impossible to do them in XSLT. > > 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. It looks like such requirement is pretty popular among IT managers ;-). I have similar experiences here. > > > 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. Now I get you! You want to make Cocoon's flow so complex that's impossible to use without your company's visual tools ;-) I'm kidding, of course! But seriously now, I think a framework should be usable without requiring complex 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. > > 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. Right, I understand you. The control flow layer I propose will not preclude you from using your favorite engine. I just hope that once Cocoon blocks are a reality, we'll be able to implement all these functionalities as separate blocks, which you can assemble as you wish. 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]
