forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Conflict resolution (Re: URI spaces: source, processing, result)
Date Fri, 13 Dec 2002 08:23:17 GMT
Nicola Ken Barozzi wrote:

>>> Concern 1 : links
>>> -------------------
>>>
>>>  href="linkmap:my/site/home"  -(lookup)->   href="http://www.home.it/"
>>>  href="javadocs:MyClass"      -(resolve)->  href="javadocs/MyClass"
>>
>>
>>
>> I'm not sure I see the difference between 'lookup' and 'resolve'. Can 
>> you elaborate more on this?
> 
> 
> Lookup is simply something like this:
> 
>  <linkmap>
>    <link1 href="blah"/>
>    <link2 href="blah"/>
>    ...
>  </linkmap>
> 
> I ask for link1, and there is a lookup of where it is and the 
> corresponding href is taken.
> 
> As for resolving, it involves more complicated rewriting rules that have 
> to be set in code.
> 
> for example, to be able to do
> 
>   href="javadocs:package.mclass"
>             -(resolve)->href="jdocs/package/MyClass"
> 
> I need to have a JavadocsResolver that is configured with  the base 
> javadocs URI (the resulting one, not the one of the source which is 
> concern 2)
> 
>   so it can do javadocs: -> jdocs/
> 
> and then append the path to the package from the package names
> 
>   package.mclass -> package/MyClass

Gotcha.

>>> Concern 2 : source finding
>>> ---------------------------
>>>
>>>  href="javadocs/MyClass"  -(sitemap)-> src="../../javadocs/MyClass"
>>
>>
>>
>> I see this.
> 
> 
> 
>>> Concern 3 : Sitemap selection
>>> ------------------------------
>>>
>>>  src="../../javadocs/MyClass"  -(CAP)-> execute ReaderPipeline
>>
>>
>>
>> But again, I'm not sure I see your point here.
> 
> 
> Let's say it with xml->html.
> 
> If I got the final link in concern 1, and founf the source file in 
> concern 2, I need now to select the correct transformation to apply.
> 
> Since I don't partition the URI space to do this (as Cocoon is normally 
> used), I find myself that the URIs are unable to make me match a correct 
> pipeline.
> 
> The extension of the source gives me a first hint, so I can match on 
> that. But then, I have
> 
>  - destination URI with the output info
>      /URI/to/file.html
> 
>  - source file(s)
>      /path/to/file.xml
> 
> but I still don't know what to do with it. The xml can have a 
> document11DTD, a changes10 DTD, a todo10 DTD, etc.
> 
> So I use the sourcetype action to peek into the file, get the DTD, and 
> select the correct transformation. In our case we would transform DTDs 
> that are not document11 to that format, so we can skin them all later on 
> with the same skin.

Ok, got it.

>>>> 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. 
>>
>>
>>
>> Nicola, please, try to be less emotional, it's not helping your point 
>> to come across.
>>
>> *must* is a pretty tension-creating word, expecially in a discussion 
>> with divergence.
>>
>> While I agree with your point of view, I also see Jeff's.
>>
>> Some of us would sacrifice architectural coherence (and maintenance 
>> ease) for speed, some of us would do the opposite.
>>
>> I'm not sure there is a perfect solution for this problem, but it's 
>> definately worth seeking it in a friendly and open way.
> 
> 
> IMHO premature optimization usually does not solve problems.

Jeff is not tryng to do premature optimization, but he's, quite validly, 
objecting the use of the Cocoon CLI and the reason why that code is 
maintained by a community which is not focused generation of static web 
sites unlike this one.

Sure, one of his points is performance, and I believe he vastly 
understimates the architectural challenges of writing such a CLI 
interface without sacrificing major architectural benefits.

But I'll be very happy to be proven wrong.

>>> What can't Cocoon do? CLI has problems with crawling? then let's fix 
>>> that.
>>
>>
>> I wrote the Cocoon CLI but I didn't optimize it. I'm sure there is 
>> *tons* of room for speed improvement at the algorithmic level.
> 
> 
> And work is being done in the Cocoon scratchpad.

Really? where is it? I couldn't find it.

-- 
Stefano Mazzocchi                               <stefano@apache.org>
--------------------------------------------------------------------




Mime
View raw message