Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F3BE867.5000808@pcextremist.com>
Date: Thu, 14 Aug 2003 12:52:07 -0700
From: Miles Elam <miles@pcextremist.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.3) Gecko/20030327 Debian/1.3-4
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Views for readers
References: <F6BBF635-CE5F-11D7-A9E2-000393CFE402@codeconsult.ch>
 <3F3B9B52.2040907@anyware-tech.com> <3F3BA7FA.4040402@verizon.net>
 <3F3BAA88.4080403@anyware-tech.com> <3F3BBE1F.1000603@pcextremist.com>
 <3F3BC5E0.40705@anyware-tech.com> <3F3BCB10.8090302@pcextremist.com>
 <3F3BDA82.6020404@anyware-tech.com>
In-Reply-To: <3F3BDA82.6020404@anyware-tech.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Sylvain Wallez wrote:

>> The functionality for all readers would obviously be the same: move 
>> these bytes from here to there.  But yes, the codified mapping I 
>> think is important.
>
>
> Please read carefully : I wrote *generators* !! This isn't about 
> moving bytes, but about producing an XML document. 


Au contraire mon fr�re, this is implemented with generators but it is 
about pulling searchable info out of arbitrary binary data.  The first 
step to that goal is to standardize it -- therefore generators are 
added.  The issue is about *readers* and the custom formats they 
encompass not being indexable.

>> You're mixing the <map:act> with a </map:match>, but I get the idea. 
>
>
> Picky guy, eh ? 


You know it.  :)

> Readers already are universal exit points : once you encounter a 
> reader, sitemap processing is terminated. <map:read> and 
> <map:serialize> are like a "return" statement in Java. 


Not according to the code, they're not.  Check out 
AbstractProcessingPipeline.java.  There are method bodies like:

    public void setGenerator (String role, String source, Parameters 
param, Parameters hintParam)
    throws ProcessingException {
        if (this.generator != null) {
            throw new ProcessingException ("Generator already set. You 
can only select one Generator (" + role + ")");
        }
        if (this.reader != null) {
            throw new ProcessingException ("Reader already set. You 
cannot use a reader and a generator for one pipeline.");
        }
    ...

and

    public void setReader (String role, String source, Parameters param, 
String mimeType)
    throws ProcessingException {
        if (this.reader != null) {
            throw new ProcessingException ("Reader already set. You can 
only select one Reader (" + role + ")");
        }
        if (this.generator != null) {
            throw new ProcessingException ("Generator already set. You 
cannot use a reader and a generator for one pipeline.");
        }
    ...


Either the policy was in effect when this file (and its subclasses) were 
made or someone put constraining statements in that serve no purpose.  
The file was last modified on August 6th of this year.  If the policy 
has changed, no one told the code.

> No consequence : this is how the sitemap works today, and the above is 
> valid, even if we can consider that the sitemap engine should more 
> strict and signal that there's some unreachable code. 


I can't speak to validity, but this is NOT how it works today.

> To add more to the confusion, in both your and my example, we can even 
> avoid writing the <map:serialize> statement. Since some additional 
> filtering occurs beforehand (either through the action or through 
> reader labels), this statement is never reached and is useless ! 


In other words, the pipeline is full of side effects and dependant upon 
things happening behind the curtain (to use a Wizard of Oz reference).  
You'd be right in that it adds to the confusion.  I agree with Vadim.  
This is obfuscation in exchange for two lines of verboseness.

- Miles Elam