Il giorno 17/apr/04, alle 20:24, Ralph Goers ha scritto:
Frankly, I'd prefer that the current 2.2 become 3.0 and the
incompatible
changes go into a new 2.2. It is my impression that what is now in
2.2 is
going to end up being quite different from 2.1 and that it should not
just
be a point
Il giorno 17/apr/04, alle 20:28, Christopher Oliver ha scritto:
I think you can use a combination of session attributes and jx macros
to get the effect you want, e.g.
// Flow script
function toSAX(str, consumer) {
...
}
cocoon.session.setAttribute(stringToSAX, toSAX);
So you can set a
On 18.04.2004 10:14, Ugo Cei wrote:
Il giorno 17/apr/04, alle 20:24, Ralph Goers ha scritto:
Frankly, I'd prefer that the current 2.2 become 3.0 and the incompatible
changes go into a new 2.2. It is my impression that what is now in
2.2 is
going to end up being quite different from 2.1 and
On 17.04.2004 12:38, Nicola Ken Barozzi wrote:
In any case, what I see is that Cocoon has gotten many contracts wrong.
In particular it has been coded using generic Cocoonish exceptions that
were meant to gobble up the source exceptions from the start. In fact we
can say that what seems now as
Ralph Goers dijo:
It is highly unlikely that the project I am working on will use 2.2 as we
have to be in production early next year and a significant amount of work
has already been done.
I am very much in favor of continuing to add new features to 2.1 (such as
the patch I just submitted),
Antoni Gallardo wrote:
Ralph Goers dijo:
It is highly unlikely that the project I am working on will
use 2.2 as
we have to be in production early next year and a
significant amount
of work has already been done.
I am very much in favor of continuing to add new features
to 2.1
Antonio Gallardo agallardo at agssa.net writes:
For an example see
http://thread.gmane.org/gmane.text.xml.cocoon.cvs/11901. A replacement
of hand-written code with commons lang code got completely lost in a
huge list of style changes.
I really don't understand things now. First was
On 18.04.2004 11:21, Carsten Ziegeler wrote:
A question (just trying to understand): that means
we can also drop the support for old avalon components in
3.0. Is this correct?
We *could* do this, but I hope we will not :) Given the discussions
about blocks here and the recent discussions over
Ralph Goers wrote:
It is highly unlikely that the project I am working on will
use 2.2 as we have to be in production early next year and a
significant amount of work has already been done.
I am very much in favor of continuing to add new features to
2.1 (such as the patch I just
Carsten Ziegeler dijo:
Antoni Gallardo wrote:
Ralph Goers dijo:
It is highly unlikely that the project I am working on will
use 2.2 as
we have to be in production early next year and a
significant amount
of work has already been done.
I am very much in favor of continuing to add new
- message key=datatype.conversion-failedKeine gültige {0}./message
+ message key=datatype.conversion-failedUnültige(s) {0}./message
Unültige ?!
Stephan.
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
Could it be that you are using both Jexl and XPath tags?
Stephan Coboos wrote:
Hello,
I've tried to retrieve an object within a JXTemplate:
#{//foo/bar}
This works fine outside any forEach. If I'am using it inner forEach,
nothing will be printed out:
jx:forEach var=something items=${myList}
In my opinion, when you go from one major release to the next you are free
to completely rewrite the product if you choose. However, providing backward
compatibility is always beneficial to your client base. Look at how long MS
supported old DOS programs in Windows. At some point it isn't cost
Stefano Mazzocchi wrote:
...
I think input modules *are*not*
necessary once you have a clearly defined way for flow to pass
parameters to the sitemap.
I do understand this is radical and i'm open for constructive criticism,
but please come up with examples to show me why you really need
Stefano Mazzocchi wrote:
Guido Casper wrote:
Why do flow people constantly fall back using Java classes?
In my case, I tried to avoid it as the plague.
Sorry, hit the wrong key and sent the email ;-) Let me continue.
Do they put to much into the flow layer?
The expectations for the flow
Carsten Ziegeler wrote:
Ralph Goers wrote:
It is highly unlikely that the project I am working on will
use 2.2 as we have to be in production early next year and a
significant amount of work has already been done.
I am very much in favor of continuing to add new features to
2.1 (such as
Ralph Goers wrote:
1. I don't understand why you need separate repositories.
Why are CVS branches not good enough?
Yes, we discussed this some time ago and there were many reasons
that a new repository is better and that it makes migration
to subversion easier (at least I think this was
Don't worry. It takes a lot to shut me up. :)
I think we in general agreement.
Ralph
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 18, 2004 10:32 AM
To: [EMAIL PROTECTED]
Subject: RE: Continue Development of 2.1.x
However, I am not a
Stefano Mazzocchi wrote:
I don't even have a real proposal. But I'm thinking about restricting
flow to FOM and flow-intended components (or their flow-intended
interface like with CForms). Another part may be some guidelines on
how to create (which should be simple of course :-) and use such
I mean that our core documentation, i.e. the xdocs and the key Wiki
pages, should be be written by this community and should be the
definitive view on the topic.
Aha, that's a clear point. Especially the latter. I currently have a feeling
that definitive views on several topics are changing
Ugo Cei wrote:
Il giorno 17/apr/04, alle 20:28, Christopher Oliver ha scritto:
I think you can use a combination of session attributes and jx macros
to get the effect you want, e.g.
// Flow script
function toSAX(str, consumer) {
...
}
cocoon.session.setAttribute(stringToSAX, toSAX);
So
Christopher Oliver wrote:
I can't say that I fully understand your problem, but I just looked at
o.a.c.f.util.JavascriptHelper, and that appears to have some major
bugs. If it isn't called from a flow script it uses a static
JavaScript object as the top level scope (where JS global variables
No. That won't work. With the current implementation of JXTG XPath
evaluation of absolute paths with a forEach only works if the
expression passed to forEach is an XPath expression. Does this work:
jx:forEach var=something items=#{myList}
#{//foo/bar}
/jx:forEach
Chris
Stephan Coboos
I do hope someone can look at this and tell me where I'm wrong.
Bye, Helma
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, 15 April 2004 23:31
To: [EMAIL PROTECTED]
Subject: Jexl and JXPath give different results!
Hi,
I've been fiddling around
Sylvain Wallez wrote:
Christopher Oliver wrote:
I can't say that I fully understand your problem, but I just looked
at o.a.c.f.util.JavascriptHelper, and that appears to have some major
bugs. If it isn't called from a flow script it uses a static
JavaScript object as the top level scope
Does someone know what's wrong? I get a timeout on cocoondev.org (blogs,
wiki etc.).
Bye, Helma
[EMAIL PROTECTED] wrote:
Does someone know what's wrong? I get a timeout on cocoondev.org (blogs,
wiki etc.).
AOIndustries, which hosts the Wiki, has had a power outage. They are in
the process of repowering all of the machines as we speak (I've just
talked to them on the 'phone about my own
Thanks.
Helma
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Sunday, 18 April 2004 21:42
To: [EMAIL PROTECTED]
Subject: Re: Cocoondev.org offline?
[EMAIL PROTECTED] wrote:
Does someone know what's wrong? I get a timeout on
cocoondev.org (blogs,
wiki
Il giorno 18/apr/04, alle 21:01, Christopher Oliver ha scritto:
The above approach has a serious drawback anyway - namely, that it
won't work for sub-sitemaps. They share the same session and would
overwrite each other's session attributes.
Do you really need to use the session? Can't you store
On Sun, Apr 18, 2004 at 10:41:10PM +0200, Ugo Cei wrote:
Il giorno 18/apr/04, alle 21:01, Christopher Oliver ha scritto:
The above approach has a serious drawback anyway - namely, that it
won't work for sub-sitemaps. They share the same session and would
overwrite each other's session
Carsten Ziegeler wrote:
The development of blocks for 2.2 has started, but as others have
already pointed out, it might take time to get it implemented
and running well.
So, I would suggest that we change our development plan a little
bit and consider adding those features to our 2.1.x code base
Our latest CVS head has (at least) one failing testcase:
Testcase: testNormalizedFilename took 0,158 sec
Caused an ERROR
0
java.lang.ArrayIndexOutOfBoundsException: 0
at
org.apache.cocoon.util.IOUtils.normalizedFilename(IOUtils.java:203)
at
Christopher Oliver dijo:
Ugo Cei wrote:
Il giorno 17/apr/04, alle 20:28, Christopher Oliver ha scritto:
I think you can use a combination of session attributes and jx macros
to get the effect you want, e.g.
// Flow script
function toSAX(str, consumer) {
...
}
Leszek Gawron dijo:
On Sun, Apr 18, 2004 at 10:41:10PM +0200, Ugo Cei wrote:
Il giorno 18/apr/04, alle 21:01, Christopher Oliver ha scritto:
The above approach has a serious drawback anyway - namely, that it
won't work for sub-sitemaps. They share the same session and would
overwrite each
Guido Casper dijo:
I think that cocoon.getComponent(role) would be enough if writing those
components would be as painless as writing flowscript. No need for more
complex stuff.
I don't think developers aren't eager to write reusable components. But
currently it's just that hard to come up
36 matches
Mail list logo
