cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [heads up!] new error handling fails weirdly!
Date Mon, 07 Apr 2003 12:20:41 GMT
Stefano Mazzocchi wrote:

>on 4/7/03 11:05 AM Sylvain Wallez wrote:
>
>  
>
>>Before reading further, please check 
>>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104923290631009&w=2
>>    
>>
>
>Oh, gosh, how I did I miss that?
>
>Great job, Sylvain, really great job.
>

Thanks :-)

<snip/>

>>We have to choose between explicit behaviour driven by the 'type' 
>>attribute as explained above, or some automagic assumptions in the 
>>sitemap engine. I'm in favor of the first solution.
>>
>>We can also have a configuration of the <sitemap> in cocoon.xconf 
>>allowing to choose between 2.1 strict mode or 2.0 automagic mode.
>>    
>>
>
>Now that I think of it, when I designed the sitemap I thought that
>things like these would have emerged so that's the reason why the
>sitemap namespace is versioned.
>

I already suggested this when we've discussed about the name of what is 
now <map:pipes> (see [1]). The TreeProcessor was designed to be able to 
run different languages simultaneously (that was at a time where we 
envisioned the flow to be described in XML).

>So, what about having the sitemap processor behave differently depending
>on the *version* of the sitemap namespace used? That would allow
>*complete* transparent and smooth transition (no changes whatsoever!)
>and also allow people to mix and match different sitemaps as they go to
>adapt their system incrementally.
>

For now, the language definition used by the TreeProcessor is defined on 
<map:mount> (a feature yet unused), which is obviously the wrong way : 
the parent sitemap shouldn't have to care about the language of the 
mounted sitemap.

It's rather easy to change this this so that the language is defined by 
the name and namespace of the root element of the sitemap.

>This is what I call a smooth transition path.
>
>What do you think?
>

+1 from my developper point of view, but I'm wondering about what is the 
easiest for our user community :
- a clear message on screen (since this morning !) stating where the 
problem lies and how to fix it,
- a new namespace, meaning obsolescence (even if still compatible) of 
books and tools (e.g. sunBow).

If we choose to have a new namespace, what about including the 
flow-related stuff (<map:flow> etc) in it, since these are 2.1-only 
statements ?

Ah, and another item on the new sitemap wishlist : allow selectors to 
provide sitemap variables (see [2]). I'm really frustrated by the 
limitation selectors have compared to matchers.

Thoughts ?

Sylvain

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104221105317073&w=2
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104800258519389&w=2

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



Mime
View raw message