Re: cocoon-template incompatible change
On 8/26/07, Leszek Gawron [EMAIL PROTECTED] wrote: ...to tell you the truth I have never used jx:import with context set, has anymone?... Me. When importing a JX template that renders a business object, setting that object as the context helps in making the imported template reusable, without knowledge of what's importing it. -Bertrand
Re: cocoon-template incompatible change
Grzegorz Kossakowski wrote: 2.a. remove markLocalContext() in StartPrefixMapping and cleanupLocalContext() in EndPrefixMapping. This clearly has side effect I am not able to analyze. I am not even sure this will work properly as some properties of object model will probably get overriden. Please comment. 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. Doesn't NamespacesTable take care of that? -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: cocoon-template incompatible change
Joerg Heinicke wrote: On 26.08.2007 16:07 Uhr, Grzegorz Kossakowski wrote: Are these valid xml files?: Nit-picking: None of them is valid as there is nothing to validate against like a DTD or a schema. You can only talk about well-formedness. yep, sorry for that - I mix it all the time. 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). That's not correct. This one is not well-formed, it should result in a undeclared namespace prefix-exception. ok, int this case cocoon template behaves properly: root xmlns:jx=http://apache.org/cocoon/templates/jx/1.0; foo:foo xmlns=http://foor.org/bar/1.0; something/ /foo:foo foo:foo something/ /foo:foo /root raises an SAXParseException. what about this one: root xmlns:jx=http://apache.org/cocoon/templates/jx/1.0; foo:foo xmlns=http://foo.org/bar/1.0; something/ /foo:foo foo:foo xmlns=http://muu.org/foo/2.0; something/ /foo:foo /root I get also org.xml.sax.SAXParseException: The prefix foo for element foo:foo is not bound. this works properly (switched default namespace to foo namespace): root xmlns:jx=http://apache.org/cocoon/templates/jx/1.0; foo:foo xmlns:foo=http://foo.org/bar/1.0; something/ /foo:foo foo:foo xmlns:foo=http://muu.org/foo/2.0; something/ /foo:foo /root -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: cocoon-template incompatible change
Leszek Gawron pisze:
Grzegorz Kossakowski wrote:
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.
Doesn't NamespacesTable take care of that?
It does but it's really not clear that we put object (NamespacesTable) on
ObjectModel and modify it
afterwards. That's why I decided to put it again every time it is modified to
keep everything as
clean as possible.
I saw that you removed this from StartPrefixMapping. I would like to strongly
underline that it's
*not* reliable solution because it does *not* fix all scoping problems but only
the one you have
come with.
With template code following:
root
jx:if test=true
jx:set var=foo value=bar/
/jx:if
test${foo}/test
/root
Will result as:
root
testbar/test
/root
instead of:
root
test/
/root
I'm going to add this as another test case.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: cocoon-template incompatible change
Grzegorz Kossakowski wrote:
Leszek Gawron pisze:
Grzegorz Kossakowski wrote:
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.
Doesn't NamespacesTable take care of that?
It does but it's really not clear that we put object (NamespacesTable) on
ObjectModel and modify it
afterwards. That's why I decided to put it again every time it is modified to
keep everything as
clean as possible.
I saw that you removed this from StartPrefixMapping. I would like to strongly
underline that it's
*not* reliable solution because it does *not* fix all scoping problems but only
the one you have
come with.
With template code following:
root
jx:if test=true
jx:set var=foo value=bar/
/jx:if
test${foo}/test
/root
Will result as:
root
testbar/test
/root
instead of:
root
test/
/root
I may be biased but I would expect exactly the first case. I made a
mistake in previous mail proposing jx:if to be scoped. Please mind that
jx:set always puts a variable in current scope so you are not able to
change variable value:
jx:set var=foo value=bar/
jx:if test=true
jx:set var=foo value=bazzz/
/jx:if
test${foo}/test
/root
should result in testbazzz/test otherwise people will get very
confused. A common user won't find the case much different from:
jx:set var=foo value=bar/
jx:set var=foo value=bazzz/
test${foo}/test
which in turn works as expected.
Long time ago we have already discussed about introducing jx:declare
along with jx:set. I cannot recall if any consensus was met.
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: cocoon-template incompatible change
Leszek Gawron pisze:
I may be biased but I would expect exactly the first case. I made a
mistake in previous mail proposing jx:if to be scoped. Please mind that
jx:set always puts a variable in current scope so you are not able to
change variable value:
jx:set var=foo value=bar/
jx:if test=true
jx:set var=foo value=bazzz/
/jx:if
test${foo}/test
/root
should result in testbazzz/test otherwise people will get very
confused. A common user won't find the case much different from:
jx:set var=foo value=bar/
jx:set var=foo value=bazzz/
test${foo}/test
which in turn works as expected.
Long time ago we have already discussed about introducing jx:declare
along with jx:set. I cannot recall if any consensus was met.
I remember that I have read that discussion and I agree that there was no clear
consensus.
I also remember that there were several folks expressing their opinion that jx
should as far from
imperative programming language as possible. I second that opinion so I'm quite
concerned with your
example. It is a programming language.
XSLT lives without such constructs so could you give us a use case for this one?
Nevertheless, we need to fix scoping now so we really need to gather some
consensus when new local
context should be established.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: cocoon-template incompatible change
Grzegorz Kossakowski wrote:
Leszek Gawron pisze:
I may be biased but I would expect exactly the first case. I made a
mistake in previous mail proposing jx:if to be scoped. Please mind that
jx:set always puts a variable in current scope so you are not able to
change variable value:
jx:set var=foo value=bar/
jx:if test=true
jx:set var=foo value=bazzz/
/jx:if
test${foo}/test
/root
should result in testbazzz/test otherwise people will get very
confused. A common user won't find the case much different from:
jx:set var=foo value=bar/
jx:set var=foo value=bazzz/
test${foo}/test
which in turn works as expected.
Long time ago we have already discussed about introducing jx:declare
along with jx:set. I cannot recall if any consensus was met.
I remember that I have read that discussion and I agree that there was no clear
consensus.
I also remember that there were several folks expressing their opinion that jx
should as far from
imperative programming language as possible. I second that opinion so I'm quite
concerned with your
example. It is a programming language.
XSLT lives without such constructs so could you give us a use case for this one?
I never used one like this :) Still the problem remains as not every
cocoon user knows xslt and the example I gave would feel natural for him.
Nevertheless, we need to fix scoping now so we really need to gather some
consensus when new local
context should be established.
My proposal is:
No new scope for:
- any plain xml element (namespaced or not). by plain I mean not macro
invocation.
- jx:import without context set
- formatting instructions (jx:formatDate, jx:formatNumber)
New strict scope for (strict scope - no inheritance, still all cocoon.*
should be available):
- jx:call (same for macroName/ invocation)
- jx:import context=${bean}
- jx:macro
New inherited scope for:
- jx:forEach
- jx:if ??
- jx:choose/jx:when/jx:otherwise ??
last two (jx:if, jx:choose) are currently NOT scoped.
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: cocoon-template incompatible change
Leszek Gawron skrev:
Grzegorz Kossakowski wrote:
Leszek Gawron pisze:
...
I remember that I have read that discussion and I agree that there
was no clear consensus.
I also remember that there were several folks expressing their
opinion that jx should as far from
imperative programming language as possible. I second that opinion so
I'm quite concerned with your
example. It is a programming language.
XSLT lives without such constructs so could you give us a use case
for this one?
We should leave the behaviour of JXTG exactly as is. The template
framework (yes it actually is designed to be a framework even if we
haven't used this) makes it easy to create a new template language. So
if you don't like the way JXTG is designed you should design a new
template language that has an own generator and an own namespace.
I never used one like this :) Still the problem remains as not every
cocoon user knows xslt and the example I gave would feel natural for him.
Nevertheless, we need to fix scoping now so we really need to gather
some consensus when new local
context should be established.
My proposal is:
No new scope for:
- any plain xml element (namespaced or not). by plain I mean not macro
invocation.
- jx:import without context set
- formatting instructions (jx:formatDate, jx:formatNumber)
New strict scope for (strict scope - no inheritance, still all
cocoon.* should be available):
- jx:call (same for macroName/ invocation)
- jx:import context=${bean}
- jx:macro
New inherited scope for:
- jx:forEach
- jx:if ??
- jx:choose/jx:when/jx:otherwise ??
last two (jx:if, jx:choose) are currently NOT scoped.
We had a discussion about what to have in a new CTemplate language, see
http://marc.info/?l=xml-cocoon-devm=110942299719102w=2. Maybe it is
time to review if the ideas there still holds and then continue the work
on creating a CTemplate language.
/Daniel
Re: cocoon-template incompatible change
Daniel Fagerstrom wrote:
Leszek Gawron skrev:
Grzegorz Kossakowski wrote:
Leszek Gawron pisze:
...
I remember that I have read that discussion and I agree that there
was no clear consensus.
I also remember that there were several folks expressing their
opinion that jx should as far from
imperative programming language as possible. I second that opinion so
I'm quite concerned with your
example. It is a programming language.
XSLT lives without such constructs so could you give us a use case
for this one?
We should leave the behaviour of JXTG exactly as is. The template
framework (yes it actually is designed to be a framework even if we
haven't used this) makes it easy to create a new template language. So
if you don't like the way JXTG is designed you should design a new
template language that has an own generator and an own namespace.
Who did you address this statement to? Me or Grzegorz?
Thing is last refactorings introduced backward incompatibilities. I
tried to upgrade to next internal release and my webapp went nuts. By
saying we should leave the behaviour as is you mean we should keep
those incompatible changes?
I never used one like this :) Still the problem remains as not every
cocoon user knows xslt and the example I gave would feel natural for him.
Nevertheless, we need to fix scoping now so we really need to gather
some consensus when new local
context should be established.
My proposal is:
No new scope for:
- any plain xml element (namespaced or not). by plain I mean not macro
invocation.
- jx:import without context set
- formatting instructions (jx:formatDate, jx:formatNumber)
New strict scope for (strict scope - no inheritance, still all
cocoon.* should be available):
- jx:call (same for macroName/ invocation)
- jx:import context=${bean}
- jx:macro
New inherited scope for:
- jx:forEach
- jx:if ??
- jx:choose/jx:when/jx:otherwise ??
last two (jx:if, jx:choose) are currently NOT scoped.
We had a discussion about what to have in a new CTemplate language, see
http://marc.info/?l=xml-cocoon-devm=110942299719102w=2. Maybe it is
time to review if the ideas there still holds and then continue the work
on creating a CTemplate language.
Do you bookmark these? I never seem to be able to find the right thread
to reference and you're always shootings with URLs. :)
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: cocoon-template incompatible change
Daniel Fagerstrom wrote: We had a discussion about what to have in a new CTemplate language, see http://marc.info/?l=xml-cocoon-devm=110942299719102w=2. Maybe it is time to review if the ideas there still holds and then continue the work on creating a CTemplate language. Why not adding support for jstl instead of inventing our own wheel? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: cocoon-template incompatible change
Leszek Gawron skrev: Daniel Fagerstrom wrote: Leszek Gawron skrev: Grzegorz Kossakowski wrote: Leszek Gawron pisze: ... I remember that I have read that discussion and I agree that there was no clear consensus. I also remember that there were several folks expressing their opinion that jx should as far from imperative programming language as possible. I second that opinion so I'm quite concerned with your example. It is a programming language. XSLT lives without such constructs so could you give us a use case for this one? We should leave the behaviour of JXTG exactly as is. The template framework (yes it actually is designed to be a framework even if we haven't used this) makes it easy to create a new template language. So if you don't like the way JXTG is designed you should design a new template language that has an own generator and an own namespace. Who did you address this statement to? Me or Grzegorz? Grzegorz Thing is last refactorings introduced backward incompatibilities. I tried to upgrade to next internal release and my webapp went nuts. By saying we should leave the behaviour as is you mean we should keep those incompatible changes? No I mean that we should keep the behaviour that we have in 2.1.x for JXTG. ... We had a discussion about what to have in a new CTemplate language, see http://marc.info/?l=xml-cocoon-devm=110942299719102w=2. Maybe it is time to review if the ideas there still holds and then continue the work on creating a CTemplate language. Do you bookmark these? I never seem to be able to find the right thread to reference and you're always shootings with URLs. :) No I tend to remember what I have written and then I search for my name in marc.info, and browse backwards until I find the thread. /Daniel
Re: cocoon-template incompatible change
Carsten Ziegeler skrev: Daniel Fagerstrom wrote: We had a discussion about what to have in a new CTemplate language, see http://marc.info/?l=xml-cocoon-devm=110942299719102w=2. Maybe it is time to review if the ideas there still holds and then continue the work on creating a CTemplate language Why not adding support for jstl instead of inventing our own wheel? Seem like a good idea, JSTL core and JSTL XML (what is the difference?) seem to contain about the same functionality as JXTG. I would have prefered getting rid of the set tag though. Any idea about how to implement it? Is there any SAX generating implementation that we could embed and reuse as a generator? Or maybe a STL implementation that we could reuse inside our template framework? Or do you mean that we implement the STL tags oursevelves? /Daniel
Re: cocoon-template incompatible change
Daniel Fagerstrom wrote: Seem like a good idea, JSTL core and JSTL XML (what is the difference?) seem to contain about the same functionality as JXTG. I would have prefered getting rid of the set tag though. We *could* decide to just support a well-defined sub set, but I think it makes more sense to go with the standard. Any idea about how to implement it? Is there any SAX generating implementation that we could embed and reuse as a generator? Or maybe a STL implementation that we could reuse inside our template framework? Or do you mean that we implement the STL tags oursevelves? Actually I don't know - this is a think I have on my long nice-to-have-wish-list-for-cocoon for years now, but never had time to look into. I hope that we could just reuse something - if we have to implement the whole stuff ourselves, then I would forget about it. But I guess that there is something out there. Perhaps we could also just use a jsp compiler and are done. In that case we would support more than JSTL but I wouldn't mind. I guess people would love to code JSPs in Cocoon (whether I think that this is a good idea or not, doesn't matter). Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: cocoon-template incompatible change
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
Seem like a good idea, JSTL core and JSTL XML (what is the difference?)
seem to contain about the same functionality as JXTG. I would have
prefered getting rid of the set tag though.
We *could* decide to just support a well-defined sub set, but I think it
makes more sense to go with the standard.
Any idea about how to implement it? Is there any SAX generating
implementation that we could embed and reuse as a generator? Or maybe a
STL implementation that we could reuse inside our template framework? Or
do you mean that we implement the STL tags oursevelves?
Actually I don't know - this is a think I have on my long
nice-to-have-wish-list-for-cocoon for years now, but never had time to
look into. I hope that we could just reuse something - if we have to
implement the whole stuff ourselves, then I would forget about it. But I
guess that there is something out there. Perhaps we could also just use
a jsp compiler and are done. In that case we would support more than
JSTL but I wouldn't mind. I guess people would love to code JSPs in
Cocoon (whether I think that this is a good idea or not, doesn't matter).
Carsten
sql:setDataSource var=testDB
url=jdbc:mysql://localhost/test,com.mysql.jdbc.Driver/
sql:query var=users dataSource=${testDB}
SELECT * FROM users
/sql:query
that is even worse than xsp days...
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: cocoon-template incompatible change
On 27.08.2007 4:17 Uhr, Leszek Gawron wrote: ok, int this case cocoon template behaves properly: root xmlns:jx=http://apache.org/cocoon/templates/jx/1.0; foo:foo xmlns=http://foor.org/bar/1.0; something/ /foo:foo foo:foo something/ /foo:foo /root raises an SAXParseException. I guess it does not even get to the templating stuff. It's the XML parser that should complain. what about this one: root xmlns:jx=http://apache.org/cocoon/templates/jx/1.0; foo:foo xmlns=http://foo.org/bar/1.0; something/ /foo:foo foo:foo xmlns=http://muu.org/foo/2.0; something/ /foo:foo /root I get also org.xml.sax.SAXParseException: The prefix foo for element foo:foo is not bound. this works properly (switched default namespace to foo namespace): root xmlns:jx=http://apache.org/cocoon/templates/jx/1.0; foo:foo xmlns:foo=http://foo.org/bar/1.0; something/ /foo:foo foo:foo xmlns:foo=http://muu.org/foo/2.0; something/ /foo:foo /root It's twice the expected behavior. In the first example the default namespace is set, but prefix foo is not bound. In the second it is. It is as simple as this: A namespace declaration for a particular prefix must be declared either on the element with the prefix or on one of its ancestors (parents) to be in scope. Joerg
Re: cocoon-template incompatible change
On 27.08.2007 7:35 Uhr, Carsten Ziegeler wrote: Actually I don't know - this is a think I have on my long nice-to-have-wish-list-for-cocoon for years now, but never had time to look into. I hope that we could just reuse something - if we have to implement the whole stuff ourselves, then I would forget about it. But I guess that there is something out there. The JSTL 1.1 reference implementation is provided by Apache Jakarta Taglibs [1]. For 1.2 it's supposed to be available in Glassfish. Joerg [1] http://jakarta.apache.org/taglibs/
Re: cocoon-template incompatible change
Joerg Heinicke skrev: On 27.08.2007 7:35 Uhr, Carsten Ziegeler wrote: Actually I don't know - this is a think I have on my long nice-to-have-wish-list-for-cocoon for years now, but never had time to look into. I hope that we could just reuse something - if we have to implement the whole stuff ourselves, then I would forget about it. But I guess that there is something out there. The JSTL 1.1 reference implementation is provided by Apache Jakarta Taglibs [1]. For 1.2 it's supposed to be available in Glassfish. Joerg [1] http://jakarta.apache.org/taglibs/ I took a look at the tag api [2] and it is based on java.io.Writer for output. So this makes rather hard and inefficient to use it as a Cocoon generator. As any STL implementation need to implement the javax.servlet.jsp.tagext to be usable with JSP I doubt that we can reuse any existing implementation more then as a reference. OTH it might not be that much work to implement a few of the basic STL taglibs in our template framework. They [3] seem very similar to JXTG, so we probably just need to provide modified implementations of our current tags [4]. Or maybe I'm missing some subtle details. /Daniel [2] http://java.sun.com/products/jsp/2.1/docs/jsp-2_1-pfd2/javax/servlet/jsp/tagext/package-summary.html [3] http://java.sun.com/products/jsp/jstl/1.1/docs/tlddocs/index.html [4] http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/main/java/org/apache/cocoon/template/instruction/ http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-template/cocoon-template-impl/src/main/resources/org/apache/cocoon/template/template-instructions.xml
Re: cocoon-template incompatible change
Joerg Heinicke wrote: On 27.08.2007 4:17 Uhr, Leszek Gawron wrote: ok, int this case cocoon template behaves properly: root xmlns:jx=http://apache.org/cocoon/templates/jx/1.0; foo:foo xmlns=http://foor.org/bar/1.0; something/ /foo:foo foo:foo something/ /foo:foo /root raises an SAXParseException. I guess it does not even get to the templating stuff. It's the XML parser that should complain. I understand. I just wanted to make sure jxtg fires proper start/end prefix mapping events in the right place. -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: cocoon-template incompatible change
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.
Re: cocoon-template incompatible change
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/
Re: cocoon-template incompatible change
On 26.08.2007 16:07 Uhr, Grzegorz Kossakowski wrote: Are these valid xml files?: Nit-picking: None of them is valid as there is nothing to validate against like a DTD or a schema. You can only talk about well-formedness. 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). That's not correct. This one is not well-formed, it should result in a undeclared namespace prefix-exception. Namespace declarations are not available to sibling elements. That's true. Joerg
Re: cocoon-template incompatible change
Grzegorz Kossakowski wrote:
Leszek Gawron pisze:
Hello,
Hello Leszek
previously (all my software bases on this behaviour) if a variable was
declared at imported template it was available further on:
!-- macros.jx declares foo variable --
jx:import uri=view/macros.jx/
tags${foo}/tags
previous versions showed: tagsbar/tags
currently the scope changed and the template produces: tags/tags
this produces the expected result:
!-- lets declare foo ourselves --
jx:set var=foo value=.../
!-- macros.jx modifies the tags variable --
jx:import uri=view/macros.jx/
!-- works as expected --
tags${foo}/tags
was this intentional?
I guess it's due to my changes regarding switch to new Object Model and
it was not intentional. Even thought the bahaviour you are describing is
natural it seems that no code in Cocoon samples rely on it. What's more
important, it seems that it's not covered by test cases. If it was I
could spot the regression.
Leszek, I could help you with it but to avoid confusion I would need
complete test template with exactly expected result. However, I'm not
sure when I will be able because I have broken my openSUSE installation
(too much experiments with RAID). Nevertheless I suggest to create a new
issue.
If you want to debug it yourself let us know if you need advices on how
to debug Cocoon 2.2.
no worry, got that in control already. Problem lies both in Import.java
instruction and StartPrefixMapping.java:
1. Import.java
StartDocument doc;
try {
doc = executionContext.getScriptManager().resolveTemplate(uri);
} catch (ProcessingException exc) {
throw new SAXParseException(exc.getMessage(), getLocation(), exc);
}
objectModel.markLocalContext();
if (this.select != null) {
try {
Object obj = this.select.getValue(objectModel);
objectModel.put(ObjectModel.CONTEXTBEAN, obj);
objectModel.fillContext();
} catch (Exception exc) {
throw new SAXParseException(exc.getMessage(), getLocation(), exc);
} catch (Error err) {
throw new SAXParseException(err.getMessage(), getLocation(),
new ErrorHolder(err));
}
}
try {
Invoker.execute(consumer, objectModel, executionContext,
macroContext, namespaces, doc.getNext(),
doc.getEndDocument());
} catch (Exception exc) {
throw new SAXParseException(
Exception occurred in imported template + uri
+ : + exc.getMessage(), getLocation(), exc);
}
objectModel.cleanupLocalContext();
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?)
2. StartPrefixMapping.java:
There is exactly the same problem here:
root xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
foo xmlns=http://foor.org/bar/1.0;
jx:set var=foo value=bar/
inner${foo}/inner
/foo
outer${foo}/outer
/root
as you expect the output currently is:
root xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
foo xmlns=http://foor.org/bar/1.0;
innerbar/inner
/foo
outer/
/root
With this one I'm not that sure what to do:
2.a. remove markLocalContext() in StartPrefixMapping and
cleanupLocalContext() in EndPrefixMapping. This clearly has side effect
I am not able to analyze. I am not even sure this will work properly as
some properties of object model will probably get overriden. Please comment.
2.b. introduce new methods to ObjectModel which
* register namespace local context
* unregister namespace local context without removing variable
declarations
WDYT?
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: cocoon-template incompatible change
Leszek Gawron pisze:
no worry, got that in control already. Problem lies both in Import.java
instruction and StartPrefixMapping.java:
1. Import.java
snip/
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?
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.
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?
2. If it's somehow limited should we allow global sets (I'm really reluctant to
that option)?
I think we should pattern ourselves on XSLT design.
2. StartPrefixMapping.java:
There is exactly the same problem here:
root xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
foo xmlns=http://foor.org/bar/1.0;
jx:set var=foo value=bar/
inner${foo}/inner
/foo
outer${foo}/outer
/root
as you expect the output currently is:
root xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
foo xmlns=http://foor.org/bar/1.0;
innerbar/inner
/foo
outer/
/root
With this one I'm not that sure what to do:
2.a. remove markLocalContext() in StartPrefixMapping and
cleanupLocalContext() in EndPrefixMapping. This clearly has side effect
I am not able to analyze. I am not even sure this will work properly as
some properties of object model will probably get overriden. Please
comment.
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.
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.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
cocoon-template incompatible change
Hello,
previously (all my software bases on this behaviour) if a variable was
declared at imported template it was available further on:
!-- macros.jx declares foo variable --
jx:import uri=view/macros.jx/
tags${foo}/tags
previous versions showed: tagsbar/tags
currently the scope changed and the template produces: tags/tags
this produces the expected result:
!-- lets declare foo ourselves --
jx:set var=foo value=.../
!-- macros.jx modifies the tags variable --
jx:import uri=view/macros.jx/
!-- works as expected --
tags${foo}/tags
was this intentional?
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: cocoon-template incompatible change
Leszek Gawron pisze:
Hello,
Hello Leszek
previously (all my software bases on this behaviour) if a variable was
declared at imported template it was available further on:
!-- macros.jx declares foo variable --
jx:import uri=view/macros.jx/
tags${foo}/tags
previous versions showed: tagsbar/tags
currently the scope changed and the template produces: tags/tags
this produces the expected result:
!-- lets declare foo ourselves --
jx:set var=foo value=.../
!-- macros.jx modifies the tags variable --
jx:import uri=view/macros.jx/
!-- works as expected --
tags${foo}/tags
was this intentional?
I guess it's due to my changes regarding switch to new Object Model and
it was not intentional. Even thought the bahaviour you are describing is
natural it seems that no code in Cocoon samples rely on it. What's more
important, it seems that it's not covered by test cases. If it was I
could spot the regression.
Leszek, I could help you with it but to avoid confusion I would need
complete test template with exactly expected result. However, I'm not
sure when I will be able because I have broken my openSUSE installation
(too much experiments with RAID). Nevertheless I suggest to create a new
issue.
If you want to debug it yourself let us know if you need advices on how
to debug Cocoon 2.2.
--
Grzegorz Kossakowski
