cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: continuation fear (was Re: [status & RT] design challenges)
Date Fri, 12 Apr 2002 17:58:17 GMT
On Fri, 12 Apr 2002 15:16:12 +0400, Piroumian Konstantin <> 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

Ovidiu Predescu <> (GNU, Emacs, other stuff)

To unsubscribe, e-mail:
For additional commands, email:

View raw message