cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: Cocoon2 and Dynamic Site maps
Date Sun, 25 Jun 2000 12:59:20 GMT

This is not an argument, just thoughts that are coming through my head.

Stefano Mazzocchi wrote:

> Niclas Hedhman wrote:
> > I am not exactly sure I understand the thoughts are this, but a dynamically
> > created/modified sitemap, is as powerful as a nuclear bomb with a 10 second
> > fuse.
> ROTFL :)


> The FS antipattern goes like this:
>  1) there is 1
>  2) somebody sees that 1 is not enough and 2 fixes the problem
>  3) your symmetry esthetics come up and say, why not any number?

"1" Fixes X% of the cases.
"2" fixes Y% of the remaining cases
"3" fixes Z% of the remaining cases

handled = 1 - (1 - solves(fix) )^NoOfFixes

Where to stop?? That should actually be a design policy determined in the early
analysis work.

>  1) we had PIs. This was not a good design, but PI could be dynamically
> generated.
>  2) the sitemap was proposed to patch this
>  3) now 1 + 2 = let's have a dynamically generated sitemap.
> This is the pattern that (IMHO) leads to unnecessary software
> complexity.

Componentized frameworks reduces complexity. But each component involved *may* in
turn be componentized at a lower level.
Looking at the whole, complexity might increase, but at each level complexity is
largely reduced to a small number of contracts.

> The sitemap indicates which components are used to create a resource,
> when and how.
> A few decades ago, a big antipattern was proposed: "don't use GOTO".
> This radically changed the way we think about programming, ever
> experienced the transition between BASIC and Pascal?

Are you saying that "Using GOTO" is an antipattern, or that "Not Using GOTO" is the

> On the other hand, I believe that carefully engineered practices that
> don't limit your functionality but limit the possible ways you do
> things, might greatly help in reducing costs and frustration.

Hence, the pluggable architecture found in Cocoon.
There is another angle that I have been driving lately in my own products.
By reducing the scope of a class to an absolute minimum, its implementation becomes
easier. The users of the classes, never use the classname directly, only the
defined interface, and having that in place, letting the user instantiate via a
factory out of a 'parameter', the factory can be 'enhanced' with more advanced
structures later on, without redesign.
This somewhat shows your 1,2,3 FS detection, but I just believe it simplify
long-term extendibility.

> There are times when you learn Java that you wish you had this or that
> feature from this or that other programming language. I guess everybody
> had the same feeling.

You bet!!!

> But after careful design, you were able to obtain
> the same functionality and, in my experience, gain code stability,
> readability and reduce further management costs.

You bet some more!!!
And what I miss, I can obtain with AspectJ.

> XML is more flexible than ASCII and note that _all_ programming
> languages are written in ASCII.

Most, but not all. There are programming languages going straight from visual to
binary. For instance, ladder diagrams for programming PLCs, some programmable logic
tools goes from visual to bitmasks, and I am sure we have a few more out there.

> > Just wondering in the light of Jorg's question...
> Jorg introduce a new dimension into the picture.
> I might be totally wrong, but I don't see why we need such a thing. It's
> not only FS, it's about unnecessary complexity.

I agree...

> True, many of my reasonings are pure speculations. Sometimes not even
> based on personal working experience (I am, admittedly, not that
> experienced).

Noone can be experienced in new fields. (Don't you love those 'Programmer with 5
years of Java experience', that started a couple of years ago.)

> But I never put down opinions and I'm never opposed to something just
> because I didn't think about it. I wouldn't be here if I was like that,
> don't you think?

Hm. I would say;  Everyone else wouldn't be here, if you were like that.

I essentially agrees with everything, and has not been opposing anything.
The bootom line, regarding Jorg's question;

a) The proposed SiteMap specification, including the sitemap.xml, is the default
component and has the No. 1 priority in this project.

b) Then there is a contract between Cocoon and the SiteMap component, which
(I presume) does not include the sitemap.xml file. The proposed SiteMap component
*can* be exchanged for other simpler or more complex SiteMaps. Those SiteMaps are
not part of Cocoon.


View raw message