cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Cocoon2 and Dynamic Site maps
Date Sun, 25 Jun 2000 09:57:59 GMT
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 :)
 
> However, I can imagine that certain applications would possibly want different
> pipelines depending on the request that is currently not possible with the
> sitemap specification, but I think I would recommend (at least for the
> moment) a custom designed Sitemapper in such a case. (The Sitemapper is
> pluggable, is it not?)

Exactly.

The pipeline is composed by turing-complete components. The sitemap has
nothing to do with turing functionality, it must reflect the internals
of the pipeline component model and give enough "componentization"
power.

Sure, we could do a bunch of "class.forname()" like Turbine does. I like
more structured approaches, but I totally understand they should not
limit functionality.
 
> Stefano, I just came to think about what you said about Perl; "Common things
> should be easy, complex things should be possible." Ring a bell??
> Is that not what you quickly stamp as FS?

I _never_ "quickly stamp" anything. Keep this in mind.

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?

FS is when "you follow symmetry 'alone' as design constraint".

This is a perfect example:

 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.

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?

Another pattern was: "don't reassemble you code at runtime". I
admittedly did this a couple of times to optimize some ASM routines I
wrote for 3D rendering ages ago. But it's the ultimate obfuscating
contest... even to your eyes. What you gain in speed, you loose in code
manageability. But it's not obvious to understand at first.

More recently: "don't use multiple inheritance".

In a close future: "don't use DTD, use XMLSchema".

In my book: "don't base your progams on XML PIs, use namespaces".

Now, how does this apply to us and FS? Some people believe there should
be no limitation in your power. Sendmail and mod_rewrite, for example,
both have this belief right into their core.

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.

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

XML is more flexible than ASCII and note that _all_ programming
languages are written in ASCII.
 
I admittedly could not find any good use of XML before XSLT was
proposed. In fact, the Cocoon pipeline was created to fill the whole on
the server side left by the XSLT language (which is what we now call
"serialization" and was later on proposed as xsl:output)

So, each time, I smell a "1 + 2 = 3" reasoning that is based on adding
functionality in a very foggy direction, I "stamp" FS on it.

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

Besides, this is "only" Cocoon2, we have a lifetime to improve on it,
but we need on-field experience to do this.

Cocoon pasts is full of simple choices that was good for 90% of problems
but failed miserably for the rest 10% and required complete redesign to
overcome their limitations.

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

Sometimes they are good, sometimes they are plain wrong.

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?

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



Mime
View raw message