forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Conflict resolution (Re: URI spaces: source, processing, result)
Date Thu, 12 Dec 2002 16:49:03 GMT


Jeff Turner wrote:
> On Thu, Dec 12, 2002 at 03:52:28PM +0100, Nicola Ken Barozzi wrote:
> 
> ...
> 
>>As I have already written, it's about separating the link resolving via 
>>a linkmap, form deciding where the source is, from applying the correct 
>>generation.
>>
>>Let me try to explain it again:
> 
> This time making much more sense.  An example is worth a thousand words
> of theory.
> 
> 
>>Concern 1 : links
>>-------------------
>>
>> href="linkmap:my/site/home"  -(lookup)->   href="http://www.home.it/"
>> href="javadocs:MyClass"      -(resolve)->  href="javadocs/MyClass"
> 
> So, a scheme is just an elaborate alias for a path, right?

Not only that, there is also some resolving in place.
Basically link rewriting.

>>Concern 2 : source finding
>>---------------------------
>>
>> href="javadocs/MyClass"  -(sitemap)-> src="../../javadocs/MyClass"
> 
> I gather this is where the resourcemap is used.  Can you give a sitemap
> snippet to illustrate how this fits in with the bit below?

Done off the top of my head in meta-sitemap speak ;-)

  <map:match pattern="**">
    <!-- concern 1 -->
    <map:act type="linkrewrite" src="{1}">

      <!-- concern 2 -->
      <map:act type="findsource" src="{1}">

       ...<other-matches/>...

       <map:match pattern="**.xml">
         <map:generate src="{foundsource}"/>

         <!-- concern 3 -->
         <map:call resource="transform-to-document">
           <map:parameter name="src" value="{foundsource}"/>
         </map:call>
         <map:call resource="skinit">
           <map:parameter name="type" value="document2html"/>
         <map:parameter name="path" value="{1}/{2}.xml"/>
         </map:call>
       </map:match>

    </map:act>
  </map:act>

>>Concern 3 : Sitemap selection
>>------------------------------
>>
>> src="../../javadocs/MyClass"  -(CAP)-> execute ReaderPipeline
> 
> And what would be the output of this pipeline?  A single Javadoc HTML
> file?  What about the rest?

Each request outputs one document.
How this becomes a site is a concern of the frontend.

>>>I hate seeing Ant becoming part of the Forrest equation, because it will 
>>>break webapps. At the same time, I have had this REALLY BIG argument 
>>>about external resources in the office that much, that I'm pretty sure 
>>>we can't fit everything underneath Cocoon.
>>
>>Everything must be underneath Cocoon, or we have a hybrid we cannot 
>>easily control. What can't Cocoon do?
> 
> Cocoon can't generate Javadocs, which is inherently a batch-processing
> job.  

It can, it just needs a javadoc Generator.
Give it a start dir, and it will generate a listing with the dir 
Generator, generate all javadocs there, and get on by crawling the 
directory links.

>The best Cocoon can do is pass through untransformed HTML.  Fine
> for webapps, useless for CLI generation.

I don't get this.

>>CLI has problems with crawling?  then let's fix that.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message