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
