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.markLocalContext();
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 only
supported by JXPath we cannot putting them on Object Model. If we put
something, we need to remove
it from Object Model, that's what EndPrefixMapping does:
objectModel.cleanupLocalContext();
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? If
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 Call
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 Model
implementation. I must think it over.
> I have no experience in xml namespaces area.
>
> Are these valid xml files?:
>
> <root>
> <foo:foo xmlns:foo="http://foo.org/1.0";>
> </foo:foo>
>
> <!-- different namespace, same prefix -->
> <foo:foo xmlns:foo="http://bar.org/2.0";>
> </foo:foo>
> </root>
Yes, it's valid. It's worth to say that namespace prefix does not matter at all
because it's defined
locally and makes it easier to indicate which elements belong to which
namespaces.
> <root>
> <foo:foo xmlns:foo="http://foo.org/1.0";>
> </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 (empty
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 have
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 ObjectModel
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 about
named contexts. For example, jx:if could create new local context this way:
objectModel.markLocalContext("jx:instruction");
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" found
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.
Thoughts?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
