cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [C2] (hopefully) last sitemap major changes
Date Sun, 02 Jul 2000 13:18:35 GMT
Nicola Ken Barozzi wrote:
> 
> 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!

Prego.

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

Nah, no need to wear asbesto suits around here.
 
> > 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...

So? my brother had a bunch of them :) I thought they were pretty cool.
 
> > 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.

right
 
> > 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?

Oh, sure, this is the idea, in fact. But nothing the sitemap should be
aware of.

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

This is exactly the plan, but the sitemap is completely independent on
this.... and while error handling doesn't give you control on how this
schema is created (the pipeline metaevents will be serialized with
something like this), it does allow you to control how to process this
further.

Many people expressed the need for having some users diplayed errors in
some ways and some users (mainly developers or internal people) having
access on more detailed transcritps of what's going on.

The error handling pipeline will give you the ability to implement
whatever you want with the pipeline meta-information just like it was
another generator. Thus reusing the good concept of pipeline components
and MDSC.
 
> Another thing is security.

yep, "another thing".

> Now I made my taglib for security but why not specify it in the sitemap?

For example?

> How does it relate to the contracts?

Which contracts? Sorry, I lost you here.
 
> 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.

I'm sure the Tomcat people will be very happy to know this. Did you tell
them?
 
> > 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...

No, that's not the notion of view I'm talking about.

Sure, the "view" concept is general enough to incorporate site skins,
but the views the sitemap adds semantics for are "functional views" that
can reuse the same pipe termination for a great number of resources and
must be directly requested for in non-standard concerns.

For example, you could have

 http://host/path/resource?cocoon-view="purple-with-flowers"

while you should write instead

 http://host/path/resource/purple-with-flowers

or, even better,

 http://host/path/resource

and have the sitemap match depending on session/cookie parameters,
instead of hardcoding this into the URI.

The "cocoon-view" parameter should indicate special functional views of
the resource that is a standard way to access the internal of a
resource, not a way to wrap it differently.

I hope this is clear because this notion if of extreme importance.

[which reminds me: the use of URI spaces as file system one-to-one maps
destoyed the notion of "URI space design patterns".... we must create a
collection of those in the future or poeple will have to write a couple
of sites before understanding what is right to do and what not...]
 
> > 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.

We all hope this.

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

Oh, you'll find lots of friend in this list then :-)
 
> > Let's polish it and let's rock and roll implementing it :)
> 
> Yeah! :-)

Thanks for the feedback Ken (Shiro?) :-) Very appreciated.

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