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
Joerg Heinicke pisze:
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.
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
block/cocoon-core-sample/cocoon-core-main-sample is by default enabled
to be built. The problem is it depends on cocoon-xsp-impl which is only
build with -Dallblocks.
Can I make xsp-impl to be built every time?
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at
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
Leszek Gawron pisze:
block/cocoon-core-sample/cocoon-core-main-sample is by default enabled
to be built. The problem is it depends on cocoon-xsp-impl which is only
build with -Dallblocks.
Leszek, this dependency is almost redundant because thanks to Unico's commit[1]
most of the stuff
has
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
Ugly formatting of code tag when used as inline.
--
Key: COCOON-2128
URL: https://issues.apache.org/jira/browse/COCOON-2128
Project: Cocoon
Issue Type: Bug
Components: -
Hi all,
Still annoyed with that problem.
Can anyone confirm or not ? Should I feed JIRA ?
Thanks !
--
Olivier Billard
Olivier Billard wrote:
Hi all,
Getting further after my... hum... it seems now that the shielding
classloader does not do its job, I now have the good old endorsed libs
Olivier Billard wrote:
Hi all,
Still annoyed with that problem.
Can anyone confirm or not ? Should I feed JIRA ?
Yes, please do so. I'm sorry, but I can't help with the problem till the end of
September when I'm back from my vacations.
--
Reinhard Pötz Independent Consultant,
[
https://issues.apache.org/jira/browse/COCOON-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reinhard Poetz closed COCOON-2128.
--
Resolution: Fixed
fixed in SVN by additional CSS style for code inside li and td elements.
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
I'm wondering what the opinion about the future of our cron block is? Do
we need such a thing at all? Could we just use the quartz support of Spring?
If we keep it, should we refactor it?
Now, I'm asking this because currently I need a scheduling service in a
non Cocoon environment (OSGi based).
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
Grzegorz Kossakowski pisze:
Joerg Heinicke pisze:
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
On 27.08.2007 7:38 Uhr, Carsten Ziegeler wrote:
I'm wondering what the opinion about the future of our cron block is? Do
we need such a thing at all? Could we just use the quartz support of Spring?
I'd go with Spring's Quartz integration. Our cron block has (most
probably) nothing to do with
Joerg Heinicke pisze:
On 27.08.2007 7:38 Uhr, Carsten Ziegeler wrote:
I'm wondering what the opinion about the future of our cron block is? Do
we need such a thing at all? Could we just use the quartz support of
Spring?
I'd go with Spring's Quartz integration. Our cron block has (most
Carsten Ziegeler wrote:
I'm wondering what the opinion about the future of our cron block is? Do
we need such a thing at all? Could we just use the quartz support of Spring?
If we keep it, should we refactor it?
Now, I'm asking this because currently I need a scheduling service in a
non Cocoon
Reinhard Poetz pisze:
Carsten Ziegeler wrote:
I'm wondering what the opinion about the future of our cron block is? Do
we need such a thing at all? Could we just use the quartz support of
Spring?
If we keep it, should we refactor it?
Now, I'm asking this because currently I need a
Grzegorz Kossakowski wrote:
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
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Carsten Ziegeler wrote:
I'm wondering what the opinion about the future of our cron block is? Do
we need such a thing at all? Could we just use the quartz support of
Spring?
If we keep it, should we refactor it?
Now, I'm asking this because
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
Reinhard Poetz pisze:
thanks Grek for taking care for documentation too!
No problem. If we are serious about switching to the unified expressions
documentation is a must.
I'm happy that the refered documentation about our documentation was
good enough for you to create a new documentation
I plan to release Cocoon 2.2RC2 between Sept 19th and Sept 21st, provided that I
have enough time to publish our new documentation before because it doesn't
help much if we release things without telling anybody about it ;-)
Does anybody have problems with a code freeze from 18th to 21st of
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
thanks Grek for taking care for documentation too!
No problem. If we are serious about switching to the unified expressions
documentation is a must.
I'm happy that the refered documentation about our documentation was good
enough for you to
Olivier Billard wrote:
Hi all,
The Cocoon Maven plug-in can be configured given a
useShieldingRepository configuration parameter. The effect is that all
JARs / classes are moved from WEB-INF/lib and WEB-INF/classes
respectively to WEB-INF/shielded/lib and WEB-INF/shielded/classes.
The
Reinhard Poetz pisze:
I plan to release Cocoon 2.2RC2 between Sept 19th and Sept 21st,
provided that I have enough time to publish our new documentation
before because it doesn't help much if we release things without
telling anybody about it ;-)
+1!
In response to some Carsten e-mail
Reinhard Poetz wrote:
Olivier Billard wrote:
Hi all,
The Cocoon Maven plug-in can be configured given a
useShieldingRepository configuration parameter. The effect is that
all JARs / classes are moved from WEB-INF/lib and WEB-INF/classes
respectively to WEB-INF/shielded/lib and
The GT website doesn't have much to say about recommended hotels yet
(http://www.cocoongt.org/Venue.html). Will there be some updates by the end of
the weekend? (I will be offline afterwards and would like to have a reservation
before my holidays.)
Thanks!
--
Reinhard Pötz
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
* I will change my opinion if cocoon-core doesn't contain Java code
anymore and everything is at its right place ...
I've taking a look on this issue when working on GSoC and moving stuff around.
Basically we have:
* code that can be moved
Carsten Ziegeler wrote:
I'm wondering what the opinion about the future of our cron block is? Do
we need such a thing at all? Could we just use the quartz support of Spring?
If we keep it, should we refactor it?
Now, I'm asking this because currently I need a scheduling service in a
non Cocoon
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
Leszek Gawron pisze:
Carsten Ziegeler wrote:
I'm wondering what the opinion about the future of our cron block is? Do
we need such a thing at all? Could we just use the quartz support of
Spring?
If we keep it, should we refactor it?
Now, I'm asking this because currently I need a
On 14 Aug 2007, at 08:01, Felix Knecht wrote:
I would like to deprecated HTMLArea as WYSIWYG HTML editor, because
it's no longer developed and maintained [1].
+1
Thanks,
Andrew.
--
Sourcesense: Making sense of Open Source
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web:
Hi Grzegorz,
On 23 Aug 2007, at 16:46, Grzegorz Kossakowski wrote:
Grzegorz Kossakowski pisze:
Reinhard, thanks again for invitation!
I'm just calculating costs of such journey, but I guess thanks to
my participation to GSoC it's going to be affordable for me.
I'll post definitive
On 14 Aug 2007, at 08:01, Felix Knecht wrote:
I would like to deprecated HTMLArea as WYSIWYG HTML editor, because
it's no longer developed and maintained [1].
+1
Thanks Felix
46 matches
Mail list logo
