Grzegorz Kossakowski wrote:
this one is quite obvious:
markLocalContext() should be executed only if a context object is
explicitly set with <jx:import uri="sth" context="${contextObject}"/>
(or should not?)
You are right, the problem is with local contexts. I remember that I didn't
understand what the
context attribute is for. Could you explain what is expected behaviour of
context presence and lack
of it?
to tell you the truth I have never used jx:import with context set, has
anymone?
I thought that context attribute affects imported template (replaces it's
context bean). On the
other hand, current handling of local contexts makes use of jx:set instruction
limited because there
is no option to set value globally.
It works exactly as you've described. But when you import a template
without context object the current one should be used.
Actually, I was going to revise concept of local contexts and its use in
template but forgot about
it in the end. Thanks to your discovery I guess it makes sense to think about
it a little more.
Before we fix anything I would like to see contracts of jx:set instruction
clearly stated. I think
we should answer two questions:
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).
jx:if, jx:choose, jx:forEach, etc. should create a new local context.
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.
2. If it's somehow limited should we allow global sets (I'm really reluctant to
that option)?
not needed IMO
Simply removing this instructions is not the best option because there would be
a lot of junk
(namespace declarations) laying in Object Model when, in fact, we would be out
of this namespaces.
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>
<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). Unnecessary
namespaces are cleared anyway by a filter:
XMLConsumer consumer = new AttributeAwareXMLConsumerImpl(new
RedundantNamespacesFilter(this.xmlConsumer));
2.b. introduce new methods to ObjectModel which
* register namespace local context
* unregister namespace local context without removing variable
declarations
One of my main goals was to have ObjectModel interface as small and clean as
possible. That's why I
moved namespace handling out of Object Model and introduced new namespaces
parameter in
Event#execute() method.
I believe we could sort out current problems without polluting ObjectModel as
soon as we establish
precise contracts for jx:set.
Once again: the contract of jx:set is clear. On the contrary we have
inconsistent context creation contract for all other jx:* instructions.
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
