You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Leszek Gawron <lg...@mobilebox.pl> on 2007/08/24 17:06:38 UTC
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: <tags>bar</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
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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
Posted by Joerg Heinicke <jo...@gmx.de>.
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
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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
Posted by Joerg Heinicke <jo...@gmx.de>.
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
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 8/26/07, Leszek Gawron <lg...@mobilebox.pl> 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
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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-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
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Posted by Joerg Heinicke <jo...@gmx.de>.
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
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: cocoon-template incompatible change
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: cocoon-template incompatible change
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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-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
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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 <test>bazzz</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
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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 <test>bazzz</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
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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>
> <test>bar</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 <test>bazzz</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
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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>
<test>bar</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
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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">
> <inner>bar</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/
Re: cocoon-template incompatible change
Posted by Leszek Gawron <lg...@mobilebox.pl>.
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: <tags>bar</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">
<inner>bar</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
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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: <tags>bar</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