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: http://apache.org/cocoon/templates/jx/1.0";> http://foor.org/bar/1.0";> 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
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
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
On 27.08.2007 4:17 Uhr, Leszek Gawron wrote: ok, int this case cocoon template behaves properly: http://apache.org/cocoon/templates/jx/1.0";> http://foor.org/bar/1.0";> 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: http://apache.org/cocoon/templates/jx/1.0";> http://foo.org/bar/1.0";> http://muu.org/foo/2.0";> 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): http://apache.org/cocoon/templates/jx/1.0";> http://foo.org/bar/1.0";> http://muu.org/foo/2.0";> 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
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 SELECT * FROM users that is even worse than xsp days... -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
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 skrev: Daniel Fagerstrom wrote: We had a discussion about what to have in a new CTemplate language, see http://marc.info/?l=xml-cocoon-dev&m=110942299719102&w=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
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-dev&m=110942299719102&w=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
Daniel Fagerstrom wrote: > We had a discussion about what to have in a new CTemplate language, see > http://marc.info/?l=xml-cocoon-dev&m=110942299719102&w=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
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 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-dev&m=110942299719102&w=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
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 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-dev&m=110942299719102&w=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
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: ${foo} should result in bazzz otherwise people will get very confused. A common user won't find the case much different from: ${foo} 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 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 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: > > > > > > ${foo} > > > should result in bazzz otherwise people will get very > confused. A common user won't find the case much different from: > > > > ${foo} > > 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: 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: ${foo} Will result as: bar instead of: 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: ${foo} should result in bazzz otherwise people will get very confused. A common user won't find the case much different from: ${foo} 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: > 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: ${foo} Will result as: bar instead of: I'm going to add this as another test case. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
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. http://foo.org/1.0";> 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: http://apache.org/cocoon/templates/jx/1.0";> http://foor.org/bar/1.0";> raises an SAXParseException. what about this one: http://apache.org/cocoon/templates/jx/1.0";> http://foo.org/bar/1.0";> http://muu.org/foo/2.0";> 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): http://apache.org/cocoon/templates/jx/1.0";> http://foo.org/bar/1.0";> http://muu.org/foo/2.0";> -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
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
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
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. http://foo.org/1.0";> 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
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 invocation) should create a > new context that DOES not inherit from parent context (only the > parameters explicitly passed with 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?: > > > http://foo.org/1.0";> > > > > http://bar.org/2.0";> > > 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. > > http://foo.org/1.0";> > > > > > > > > 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
Grzegorz Kossakowski wrote: this one is quite obvious: markLocalContext() should be executed only if a context object is explicitly set with (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 invocation) should create a new context that DOES not inherit from parent context (only the parameters explicitly passed with 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?: http://foo.org/1.0";> http://bar.org/2.0";> http://foo.org/1.0";> 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: > > no worry, got that in control already. Problem lies both in Import.java > instruction and StartPrefixMapping.java: > > 1. Import.java > > this one is quite obvious: > markLocalContext() should be executed only if a context object is > explicitly set with > (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: > >> http://apache.org/cocoon/templates/jx/1.0";> >> http://foor.org/bar/1.0";> >> >> ${foo} >> >> ${foo} >> > > as you expect the output currently is: > http://apache.org/cocoon/templates/jx/1.0";> > http://foor.org/bar/1.0";> > bar > > > > > 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/
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: ${foo} previous versions showed: bar currently the scope changed and the template produces: this produces the expected result: ${foo} 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 (or should not?) 2. StartPrefixMapping.java: There is exactly the same problem here: http://apache.org/cocoon/templates/jx/1.0";> http://foor.org/bar/1.0";> ${foo} ${foo} as you expect the output currently is: http://apache.org/cocoon/templates/jx/1.0";> http://foor.org/bar/1.0";> bar 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: Hello, Hello Leszek previously (all my software bases on this behaviour) if a variable was declared at imported template it was available further on: ${foo} previous versions showed: bar currently the scope changed and the template produces: this produces the expected result: ${foo} 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
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: ${foo} previous versions showed: bar currently the scope changed and the template produces: this produces the expected result: ${foo} was this intentional? -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.