cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Cocoon2 and Dynamic Site maps
Date Sun, 25 Jun 2000 13:13:27 GMT
Niclas Hedhman wrote:
> 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 :)
> ????

Rolling on the floor laughing :)
> > 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.

It's not easy at it seems since each iteration bring new complexity and
increases the number of possible problems.
> >  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.

Hey, sounds like my "separation of concerns" vangel is making roots :)
> > 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
> antipattern??

Oh, yeah sorry, "Using GOTO" is the antipattern, of course.
> > 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.

No, there are some cases where 1,2,3..n is obvious. Object polymorphism
is such a case.
> > 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.

Uh, guess I missed this one. What is it?
> > 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.

Good point.
> > > 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.

Yeah, better way to put it.
> 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.

Correct. The sitemap.xml will be the standard way to compile the
pipeline interpreters, just like you can write your own generators by
hand instead of using XSP. You can also create your own XSP-clone if you

> The proposed SiteMap component
> *can* be exchanged for other simpler or more complex SiteMaps. Those SiteMaps are
> not part of Cocoon.

Correct. You can think of creating sitemap-- schemas and use XSLT to
move to the original Cocoon sitemap, or you can write your compiled
sitemap component by hand, so you can introduce anything you want there.

This is not FS, but component polymorphism.

Of course, if your new sitemap design contains FS and becomes a hell to
maintain, well, it's your problem, not ours :)

Note: this doesn't mean the sitemap won't be complete, rather the
opposite, but it should be tuned and balanced between functionality and

I know it doesn't mean anything really... but this is the main design
goal anyway.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message