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
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
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.
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
!--
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
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
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
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:
25 matches
Mail list logo
