Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42FB4CE1.6000807@apache.org>
Date: Thu, 11 Aug 2005 15:04:33 +0200
From: Sylvain Wallez <sylvain@apache.org>
User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: svn commit: r231266 - in /cocoon/branches/BRANCH_2_1_X: ./
 src/java/org/apache/cocoon/generation/
 src/java/org/apache/cocoon/util/jxpath/ src/java/org/apache/cocoon/xml/
 src/test/org/apache/cocoon/xml/
References: <20050810153834.23695.qmail@minotaur.apache.org>
 <42FB0015.20300@mobilebox.pl> <42FB1920.9040300@apache.org>
 <42FB1D7F.1060609@mobilebox.pl> <42FB2328.70001@apache.org>
 <42FB4993.9000607@reverycodes.com>
In-Reply-To: <42FB4993.9000607@reverycodes.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Vadim Gritsenko wrote:

> Sylvain Wallez wrote:
>
>> Leszek Gawron wrote:
>>
>>> Sylvain Wallez wrote:
>>
>>
>>>> As a side note, the refactored NamespacesTable I committed 
>>>> yesterday is a killer tool to cleanly handle namespaces (see 
>>>> RedundantNamespacesFilter). I plan to use it in some transformers 
>>>> that "consume" namespaces such as i18n, xinclude, etc to ensure the 
>>>> consumed namespaces never passes through the transformer. That will 
>>>> make cleaner and smaller web pages!
>>>
>
> If transformer consumes its namespace completely, it's way more 
> efficient to simply filter out the namespace completely.


It's not always that easy, as you have to remove the startPrefixMapping 
and the endPrefixMapping. The start is easy because you've got the URI, 
but the end isn't so easy as you have to know which prefix to filter 
out, and several prefixes can be used for the same URI (or the same 
prefix can also hide a previous one).

>> I will also modify AbtractProcessingPipeline so that it dumps the 
>> full chain of locations of the pipeline when an error occurs.
>>
>> That will lead to stacktraces like:
>>
>>  <jx:forEach> - 
>> resource://org/apache/cocoon/forms/generation/jx-macros.xml:103:10
>>  <ft:repeater> - context://foo/bar.xml:23:12
>
>
> (hm, why it's context:// here - won't it usually resolve to file://?)


context:// is a convenience provided by the error2html stylesheet to 
have shorter paths. But logs contain the full path with file://

>>  <map:serialize> - context://foo/sitemap.xmap:45:6
>>  <map:transform> - context://foo/sitemap.xmap:44:6
>>  <map:generate> - context://foo/sitemap.xmap:43:6
>>  showForm() - resource://org/apache/cocoon/forms/flow/js/form.js:30:-1
>>  do_stuff() - context://foo/flow.js:10:-1
>>  <map:call> - context://foo/sitemap.xmap:20:6
>>  <map:mount> - context://sitemap.xmap:20:10
>>
>> Looks cool, eh?
>
>
> It is probably good idea to add some more context info like:
>
>   <map:transform type="bar"> - context://foo/sitemap.xmap:44:6
>   <map:generate type="foo"> - context://foo/sitemap.xmap:43:6
>
> Or may that is too much... Dunno.


Thought about this also. Actually, we can put there any information that 
is statically known. So why not.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director