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, witho
On 26.08.2007 7:29 Uhr, Grzegorz Kossakowski wrote:
Unexpectedly, Nils Kaiser has come up with much better and, in general, less
intrusive solution. He
proposed[3] to introduce custom fields where information about version specific
to the *component*
would be stored.
I don't want to rain on
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
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 sh
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 exp
Grzegorz Kossakowski wrote:
Hello,
This is a second attempt to resolve problem with inaccurate version information
in JIRA which I
described here[1]. The first one was to split up our COCOON project into
several smaller ones[2].
Unfortunately, this option had several drawbacks like broken link
Grzegorz Kossakowski skrev:
Hi Daniel,
[EMAIL PROTECTED] pisze:
Author: danielf
Date: Sat Aug 25 03:37:44 2007
New Revision: 569656
URL: http://svn.apache.org/viewvc?rev=569656&view=rev
Log:
Actually all samples work.
Modified:
cocoon/whiteboard/osgi/README.txt
I see that you are playin
As some of you might have seen in the SVN logs, I have started to work
on making Cocoon work under OSGi again [1].
This will, for the moment, not affect the trunk more than that I might
refactor or reorganize some stuff based on needs for the OSGi integration.
The main reasons for working on
Hi,
I wanted let you know that I have created Daisy site for
cocoon-expression-language module. It was
very easy because everything is explained here:
http://cocoon.zones.apache.org/daisy/cdocs/g3/1223.html
I must visit our Daisy more often; our documentation system is no less fun than
coding.
Hi Daniel,
[EMAIL PROTECTED] pisze:
> Author: danielf
> Date: Sat Aug 25 03:37:44 2007
> New Revision: 569656
>
> URL: http://svn.apache.org/viewvc?rev=569656&view=rev
> Log:
> Actually all samples work.
>
> Modified:
> cocoon/whiteboard/osgi/README.txt
I see that you are playing with OSGi
Hello,
This is a second attempt to resolve problem with inaccurate version information
in JIRA which I
described here[1]. The first one was to split up our COCOON project into
several smaller ones[2].
Unfortunately, this option had several drawbacks like broken links to the
current issues.
Unex
11 matches
Mail list logo