cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: cocoon-template incompatible change
Date Sun, 26 Aug 2007 20:07:29 GMT
Leszek Gawron pisze:
>> 1. What's the scope of variable introduced by jx:set?
> you are probably asking the wrong question. jx:set always puts a
> variable in current context. The question should be: which
> elements/instructions should trigger a new local context.
> I think new local context should never be introduced for plain xml
> elements (either local or imported, namespaced or not).

Take a look at this code from StartPrefixMapping:

        namespaces.addDeclaration(getPrefix(), getUri());
        objectModel.put(ObjectModel.NAMESPACE, namespaces);

What this code does is putting NamespaceTable object (namespaces) on Object Model. It may
be used
while some expression deeper in elements hierarchy is evaluated. Even though namespaces are
supported by JXPath we cannot putting them on Object Model. If we put something, we need to
it from Object Model, that's what EndPrefixMapping does:


That's why we need to introduce new context when encountering new namespace prefix.

> jx:if, jx:choose, jx:forEach, etc. should create a new local context.

Do you want to say that all instructions that contain other instructions create a new context?
so, I'm fine with such behaviour.

> jx:call (along with alternative <macroName/> invocation) should create a
> new context that DOES not inherit from parent context (only the
> parameters explicitly passed with <jx:call macro="macroName"
> param1="value" param2="value"/>) should be visible.

That's something new for me but after a while of thinking I agree with you. This means that
instruction will need to create it's own instance of ObjectModelImpl class that will be created
every time the call is made. That's not the best option because it couples Template and Object
implementation. I must think it over.

> I have no experience in xml namespaces area.
> Are these valid xml files?:
> <root>
>   <foo:foo xmlns:foo="">
>   </foo:foo>
>   <!-- different namespace, same prefix -->
>   <foo:foo xmlns:foo="">
>   </foo:foo>
> </root>

Yes, it's valid. It's worth to say that namespace prefix does not matter at all because it's
locally and makes it easier to indicate which elements belong to which namespaces.

> <root>
>   <foo:foo xmlns:foo="">
>   </foo:foo>
>   <!-- namespaced element outside namespace declaration -->
>   <foo:foo>
>   </foo:foo>
> </root>
> If the second one is valid we have to keep all declared namespaces till
> the end of xml file (gets worse for xmls with jx:imports). 

Second file is valid XML but second "foo" element is in the same namespace as root element
namespace) and it's full name is "foo:foo". Lack of namespace declaration makes prefix meaningless
and part of element's name (if prefix is attached to the namespace it's part of element's
name also).

Namespace declarations are not available to sibling elements.

> Unnecessary
> namespaces are cleared anyway by a filter:
> XMLConsumer consumer = new AttributeAwareXMLConsumerImpl(new
> RedundantNamespacesFilter(this.xmlConsumer));

Leszek, you are mixing two things:
1. SAX events declaring namespaces pushed down the pipeline that you say are filtered out.
2. Namespaces declaration put on Object Model that are used solely for JXPath purpose and
nothing to do with SAX events.

> Once again: the contract of jx:set is clear. On the contrary we have
> inconsistent context creation contract for all other jx:* instructions.

>From ObjectModel point of view everything is fine. StartPrefixMapping puts something on
that will need to be cleaned up later on so it needs to create local contexts.

However, what we want to is to attach variable to context upper in hierarchy. I'm thinking
named contexts. For example, jx:if could create new local context this way:


Then in jx:set we could use:

objectModel.put("variable_name", variable, "jx:instruction");

so object model would attach this variable to the first context with name "jx:instruction"
when searching the context hierarchy.

I'm not particularly happy with such approach because it pollutes Object Model API but I couldn't
come with something more elegant.


Grzegorz Kossakowski

View raw message