cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Sitemap Draft comments
Date Tue, 20 Jun 2000 11:54:25 GMT

These things might have been discussed, and if so, ignore...

a) What is the difference between the parameter "mimetype" and the
parameter "doctype"?? They are both an input to the serializer, and it
is up to the serializer to figure out what to do with them. But still
"mimetype" is an attribute, and the others are <param> tags. Not

b) Using "Access Refused" as a sample of resources is possibly a bad
idea. It will generate a lot of overhead, since the browser sends a
request, Cocoon will generate the reponse 401, then the browser will
request the user/pass, and resend the request. Only if the user press
escape, this page will be shown. I see further down, that the resource
is used for excluding hosts, in which case a 401 should not be sent at
all, but a 200.

c) <choose>/<when> is a weird name pair in my ears. Both for programmers
and non-programmers I think this feels wrong. <when> indicates a point
in time, but it is a boolean test that is performed, in which case we
normally use the notion <if>. We could also be a bit more specific
(although increasing verbosity) by <when-true> or <if-true>, which also
invites for a <if/when-false>. <choose> for me is also a bit odd, hard
to explain. <use> (<proceed>) is my suggestion(s) (slightly depending on
if more than one <when/if> section can be used/chosen). <use>/<if-true>
is a lot more intuitive to me.
That leaves the <chooser> hanging out dry. <selector> ??? I don't

d) I saw some Email that the "test" attribute is executed in Java, and
I assume the method is called on the "type" object. But the greaterThen
(line 415) is bad Java naming convention and wrong spelling, should be
verb, isGreaterThan().

e) <default> is probably too programatic for most normal people. Default
for other people is "unable to perform", such as "defaulted your mortage
payments" (who hasn't?). See below...

f)  I am still unable to figure out if all <when> sections, that tests
true are executed, or only the first one found. And whether <default> is
excuted if nothing else is executed or always. I would say that there is
perhaps a need for both. And then we would be talking of a <otherwise>
and an <also> or <always>. (Howcome all my suggested changes starts with
a vowel?)

g) The type="uri" is somewhat hardcoded in Cocoon?? But what if I want
an tricky match, which is easier expressed in Java? Couldn't that all be
solved with the use of different attributes, instead of the same name
for both, such as
<choose type="uri">
  <when match="niclas/*">
  <when test="isRestricted()">
But this then implies that there is an object instantiated for the URI
selection, and that this can be extended with my own type.
SM mention that URI matching is native to Cocoon engine and is handled
internally. Is there 'actually' a need for that?? I doubt that there are
any performance benefits of burying this natively. Put it up front!!

h) The Serializers have a src: attribute to instantiate an object, and a
handful of <param> tags. I take it that they are passed to the created
object as configuration parameters. Are we still in the Map idea of
config parameters, or could there be an arbitrary structure passed to
other classes upon instantiation?? In that case, is the <param>
well-designed for the classes in the draft??

Well, I am sorry if I am rumbling about old news, but I am trying to
catch up real quick now.
Generally speaking, I am rather pleased with the SiteMap now. A bit
surprised that Stefano hasn't shouted FS all over the place. Not yet.
But I have a feeling it is way too complicated in large URI spaces,
support for many browsers and many languages... On the other hand, it
would be possible to design a SiteMap Lite, and with XSL transform it to
the actual one. Interesting thought.

Tracing what is happening will be an essential administrator tool, and
must be considered initially. Just think about trying to figure out what
is going on with multiple level cascades...

Niclas Hedhman

View raw message