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 Fri, 13 Dec 2002 07:48:20 GMT

Stefano Mazzocchi wrote:
> Nicola Ken Barozzi wrote:
> 
>>
>>
>> Steven Noels wrote:
>>
>>> Jeff Turner wrote:
[...]
> I think this is a very healthy way to settling disagreement and I would 
> like forrest to keep the attitude of seeking consensus.

+1   Exactly what I want too.

>>> If I see 'SoC breakage', I want it to be defined. It is too much of a 
>>> vague term. We should all trust our own bellies, but not each belly 
>>> is equal. So let's please don't use SoC, IoC and FS without 
>>> explaining what problems we will encounter. And I hope we try to be 
>>> as openminded as possible, while keeping F. Brooks in mind: there is 
>>> NO silver bullet. Not even Cocoon.
>>
>> 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:
>>
>> 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


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

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

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

> Instead of seeing people ranting blindly on it, I would love to bring 
> out the details and see if this community can find better ways to do the 
> same things *and* without missing its current functionality.

Yup.

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


Mime
View raw message