Return-Path: <nicolaken@supereva.it>
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 44038 invoked from network); 1 Jul 2000 10:00:23 -0000
Received: from adamo6.supereva.it (HELO mail.supereva.it) (195.110.96.96)
  by locus.apache.org with SMTP; 1 Jul 2000 10:00:23 -0000
Received: (qmail 12129 invoked from network); 1 Jul 2000 09:59:55 -0000
Received: from unknown (HELO ARES) (151.35.2.48)
  by mail.supereva.it with SMTP; 1 Jul 2000 09:59:55 -0000
Message-ID: <00ef01bfe343$360a6c70$30022397@ARES>
Reply-To: "Nicola Ken Barozzi" <nicolaken@supereva.it>
From: "Nicola Ken Barozzi" <nicolaken@supereva.it>
To: <cocoon-dev@xml.apache.org>
References: <395CD669.DEC70286@apache.org>
Subject: Re: [C2] (hopefully) last sitemap major changes
Date: Sat, 1 Jul 2000 11:51:16 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

This is the first time I am posting something on this list, so I would like
to say hi to everyone. :-)
Before I found out about Cocoon I was planning something similar...
fortunately I found Cocoon before the code writing!
Thanks to all the Cocoon developers!
------------------- initial compliments finished -------------------

----- Original Message -----
From: "Stefano Mazzocchi" <stefano@apache.org>

> Ok, I spent the whole afternoon on this and I'm pretty happy with the
> results. Please, throw rock at it and let's see how solid this is.

We will see how solid it is only after using it! ;-)
Anyway you have your asbesto suit!

> 2) filter becomes transformer
>
> One main reason for this: filter and its verbe are the same word in
> English... this causes big troubles in sitemap validation, while
> "transform" and "transformer" are different words and have different
> semantics inside the sitemap.

transformer reminds me of small robot toys...

> 3) increased redirection capabilities
>
>  <map:redirect-to uri="..."/>
>  <map:redirect-to resource="..."/>
>
> a "resource" being a
>
>  <map:resource name="...">
>
> where the "name" attribute is the ID and "resource" is the IDREF.

+1

Imho one should use resources, it is easier when uris change, but this
doesn't mean uris are not to be allowed.

> 5) added the notion of "error handling" (which includes metaevents
> handling) as such
>
>  <map:pipeline>
>   <map:match ...>
>    ...
>   </map:match>
>   <map:handle-errors>
>    <map:transform src="./style/error-page2html.xsl"/>
>    <map:serialize/>
>   </map:handle-errors>
>  </map:pipeline>

I am using Cocoon for two projects and one is an intranet.
Here security and error handling are not an option.
When I first saw the sitemap proposal I thought it was a good idea (I still
think it is), but error handling was not in it.
Now it is... but why don't we define a standard DTD for notifications and
standard XLST for main browsers?
Something like (mixed notation)

<notify type="information|warning|exception|error|fatal">
  <title>foo_title</title>
  <description>foo_description</description>
  <message>foo_message</message>
  <stacktrace>foo.stacktrace</stacktrace>
</notify >

Another thing is security.
Now I made my taglib for security but why not specify it in the sitemap?
How does it relate to the contracts?

This is what I am using now:

  <xsl:template match="security:require-role">
     <xsp:logic>
      if (request.isUserInRole("<xsl:value-of select="@role"/>"))
       {
          <xsl:apply-templates/>
       }

      </xsp:logic>
  </xsl:template>

OFF TOPIC: By the way, I went crazy trying to make security work in Tomcat;
in the documentation they say they tested it but it doesn't work! In fact it
is bugged, they froze the wrong code, so to make it work you have to change
three lines of code and recompile, then all works ok.

> 6) added the notion of "views" and pipeline "labels".
>
> for example
>
>  <map:view name="content" generate-from="content">
>   <map:serialize type="xml"/>
>  </map:view>
>
>  <map:view name="schema" generate-from="content">
>   <map:transformer type="schema"/>
>   <map:serialize type="xml"/>
>  </map:view>
>
>  ....
>
>   <map:label name="content">
>    <map:generate src="./file/document.xml"/>
>   </map:label>
>   <map:transform src="./style/doc2html.xsl"/>
>   <map:serialize/>
>
> where it can be viewed as
>
>  g -(content)-> t -> s   [normal view]
>         +-----> t -> s   [schema view]
>         +----------> s   [content view]
>
> The sitemap allows each "producing" component (generators and
> transformers) to attach "default labels" to these components so that
>
>   <map:label name="content">
>    <map:generate src="./file/document.xml"/>
>   </map:label>
>   <map:transform src="./style/doc2html.xsl"/>
>   <map:serialize/>
>
> is totally equivalent to
>
>   <map:generate src="./file/document.xml"/>
>   <map:transform src="./style/doc2html.xsl"/>
>   <map:serialize/>
>
> if the "parser" generator (which here is default), has attached as
> default label "content"... such as in
>
>   <map:generators default="parser">
>    <map:generator type="parser" src="..." label="content"/>
>   </map:generators>
>
> this should allow us to use sitemaps for simple views (such as content
> or schema) without introducing too much sitemap-creation overhead and
> reduce readability with a bunch of <label> tags.

+2
I think it could be used to add some sort of skinning... just associate
users with different views with a taglib...

> So, please, don't assume the sitemap will do _everything_ for you....

no coffee!?!!!!!

> but I could not find any problem space that this sitemap solution space
> cannot cover... and this after 18 months of feedback from thousands of
> people.
>
> This doesn't mean it's perfect, I'd presume from my past experience it's
> not even close... but its a good step forward compared to C1 and it must
> be judged for this only.
>
> So, I consider it feature-frozen from now.

I hope it doesn't get too complicated.
Before I found Cocoon was thinking of creating a servlet for report
generation and database insertions and transactions in the intranet. The XML
i was creating was beginning to become a monster.
This is one of the first versions (the text is in Italian):

<?xml version="1.0"?>
<!DOCTYPE SQLQuerySetDB SYSTEM "SQLQuerySetDB.dtd">
<SQLQuerySetDB>
   <DBIds>
      <DBId DBref="OreLavorateDB" DBdriver="sun.jdbc.odbc.JdbcOdbcDriver"
DBname="jdbc:odbc:OreLavorate" userId="admin" userPass="admin"/>
      <DBId DBref="KeyDB" DBdriver="sun.jdbc.odbc.JdbcOdbcDriver"
DBname="jdbc:odbc:KeyDB" userId="admin" userPass="admin"/>
   </DBIds>
   <SQLQuerySet name="TestQuerySet" stylesheet="testsheet.xsl">
      <SQLQuery name="TestQuery" DB="OreLavorate" type="SELECT">
         <SQLQueryString>SELECT ? from contatti</SQLQueryString>
         <SQLQueryParameters>
            <form name="firstform" stylesheet="testsheet.xsl">
               <select name="C1" default="0">
                  <caption>Scegli un choice:</caption>
                  <choices>
                     <choice value="1">choice 1</choice>
                     <choice value="2">choice 2</choice>
                  </choices>
               </select>
               <input name="I1" default="0">
                  <caption>Inserisci:</caption>
               </input>
               <hidden name="H1" default="defaulthiddenvalue"/>
               <select name="SQLS1" default="0">
                  <caption>Scegli un choice SQL:</caption>
                  <choices>
                     <SQLQuery name="TestQuery2" DB="OreLavorate"
type="SELECT">
                        <SQLQueryString>SELECT "Gino" from
contatti</SQLQueryString>
                     </SQLQuery>
                  </choices>
               </select>
            </form>
         </SQLQueryParameters>
      </SQLQuery>
   </SQLQuerySet>
</SQLQuerySetDB>

I was creating a tree containing all transaction info, starting fron the
result wanted (report in this case).
It was getting too big and to make decision branching possible I thought of
putting forward and backward branches: A NIGHTMARE!
So +100 to the idea of keeping it simple.

> Let's polish it and let's rock and roll implementing it :)

Yeah! :-)


Nicola Ken Barozzi - AISA Industries S.p.A
http://www.aisaindustries.it/
Personal homepage at Java Guru:
http://www.jguru.com/jguru/guru/viewchannel.jsp?EID=39153
Research Activity:
Politecnico di Milano - Dipartimento di Meccanica
Piazza Leonardo da Vinci, n.32 - 20133 Milano (Italy)