[EMAIL PROTECTED] wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=25110
[Roadmap] CocoonForms - release 1.0
This bug depends on bug 24900, which changed state:
What|Old Value |New Value
Joerg Heinicke wrote:
On 06.04.2004 09:20, Marc Portier wrote:
Joerg,
I realize that 'resting my case' is not enough...
some ideas:
this sounds like the operation 'selecting a row' should be an
intrinsic feature of the repeater-widget
Yes, sounds reasonable.
In light of the above we could
i think that they are users (i'm one of those) that use to take a quick
look at gennerated from xsp .java files. For me is the best way to debug
this code.
--stavros
On Tue, 6 Apr 2004, Joerg Heinicke wrote:
On 06.04.2004 13:52, Vadim Gritsenko wrote:
It does not provide much value -
Bruno Dumon [EMAIL PROTECTED] wrote:
Haven't thought deeply about this, but just some thoughts (without
choosing either way for now):
- for Cocoon-specific components (e.g. sitemap components) it doesn't
matter that much, except for the porting effort, both for us and for
users who have
Stefano Mazzocchi [EMAIL PROTECTED] wrote:
I don't buy this.
The component portability argument is moot, it's a myth, you can't
even move components from one container to another in avalon and ECM
is deprecated, now even fortress is deprecated.
Sorry, but that's not 100% true. You can use
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=25113.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=25304.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On 07 Apr 2004, at 10:54, [EMAIL PROTECTED] wrote:
Hi,
I try to migrate webapplication (wich written in 1999 with cocoon 1.8)
From cocoon 2.1.4. But I can find the packages below:
org.apache.cocoon.processor.*;
org.apache.cocoon.framework.*;
org.apache.cocoon.transformer.*;
Nicola Ken Barozzi wrote:
Carsten Ziegeler wrote:
...
To be honest, I still don't buy the classloader problem theory. I'm
just saying that we should try to support interfaces like
Configurable etc.
For Cocoon blocks or for other components?
For all components :) A block might
Le 7 avr. 04, à 11:33, Carsten Ziegeler a écrit :
...Exactly my point :) But the current idea of blocks is to only retain
this possibility inside a sandbox which means it can't be used inside
blocks. So if I develop my app as a block, I can't use these components
inside my app!...
I thought the
Carsten Ziegeler wrote:
...
To be honest, I still don't buy the classloader problem theory. I'm just
saying that we should try to support interfaces like Configurable etc.
For Cocoon blocks or for other components?
...
And the dependency is very minimal. It's just a dependency against the
avalon
Hi,
I am a new kid on the block and work with the OJB/JDO block. Using a
database with no relations works perfectly, however when I increase
complexity and use foreign keys I fail to get it working. The following
error is what I get:
[org.apache.ojb.broker.accesslayer.RsIterator] ERROR: Error
Bertrand Delacretaz wrote:
I thought the idea was to provide an ECM-like sandbox
*inside* a block (reading Stefano's last message on this
thread), in which case you can use your Avalon components
inside a Cocoon block, but they cannot be made available to
other blocks.
But I might
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
So, like we already said before, it is *totally* possible to have a
block load avalon components thru an avalon sandbox (sort of a
avalon-cocoon adapter). This allows you to reuse your avalon
stuff AS IS. But this also means that your
Nicola Ken Barozzi wrote:
The issue is not so technical as it's of indipendence from
something that, in the good and the bad, has not helped
Cocoon be built by Gump for ages now.
As I said, we would only have a reference to avalon framework
version x.y.z - a fixed version so there shouldn't
Antonio Gallardo agallardo at agssa.net writes:
I even see no request/response cycles are saved.
Some words are missing above: I even see no problems when no request/response
cycles are saved.
Some cycles can be saved in the similar way as they are saved by DHTML.
Example: suppose you have
It does not provide much value - how many times have you looked into the
generated XSP code? And how important for you was formatting of this
generated code? I'm ok with keeping it, but, for myself, I have it
disabled (and jstyle.jar removed).
So let's start a quick vote: If
Marc Portier mpo at outerthought.org writes:
In light of the above we could even consider sending
repeaterID.radioID=row-identity (which would require to
serialize-to-string somehow this identity?)
snip what=separate backend IDs from frontend IDs/
+1
I'm still running around the hot
Sorry for the delay, I overlooked this...
Done.
Carsten
-Original Message-
From: Jon Evans [mailto:[EMAIL PROTECTED]
Sent: Monday, April 05, 2004 11:44 AM
To: [EMAIL PROTECTED]
Subject: Re: CachingURICoplet and cl:links caching too
aggressively - possible fix?
Hi,
On 4 Apr
Joerg Heinicke wrote:
Marc Portier mpo at outerthought.org writes:
In light of the above we could even consider sending
repeaterID.radioID=row-identity (which would require to
serialize-to-string somehow this identity?)
snip what=separate backend IDs from frontend IDs/
+1
I'm still
On 07 Apr 2004, at 11:09, Nicola Ken Barozzi wrote:
The issue is not so technical as it's of indipendence from something
that, in the good and the bad, has not helped Cocoon be built by Gump
for ages now.
As much as I like Gumpinal Correctness for the sanity of us Cocoon
committers, I'm not
Any chance you can post the relevent repository_user.xml snippets and
an outline at least of what they map to? More than happy to help you
work out what's going on =)
I have never seen divide by zero errors from OJB =(
Also, do you get the same problem if you try the query via the
Hi guys!
Nicola Ken Barozzi wrote:
And the dependency is very minimal. It's just a dependency against the
avalon framework api version 4.1.5 - a released version. There is no
need in following the development of Avalon.
The issue is not so technical as it's of indipendence from something
that,
Hi Brian,
I can try... let me describe what I got so far. After digging deeper
into this and producing some relevant debug statements I find the
following written on my console:
console output:
--- start snippet ---
NVTPDataAccessObject2: getArticle: called with id: 56
Steven Noels wrote:
On 07 Apr 2004, at 11:09, Nicola Ken Barozzi wrote:
The issue is not so technical as it's of indipendence from something
that, in the good and the bad, has not helped Cocoon be built by Gump
for ages now.
As much as I like Gumpinal Correctness for the sanity of us Cocoon
Leo Simons wrote:
...
avalon-framework very rarely doesn't get built by gump. It's the ECM
dependency that's causing the ripples, and the big set of dependencies
ECM has itself.
Since it seems ECM is being put into the freezer anyway, just be
pragmatic and make the gump build of cocoon depend
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28260.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Wed, 2004-04-07 at 16:19, Rolf Kulemann wrote:
On Wed, 2004-04-07 at 13:56, Michael Wechner wrote:
Rolf Kulemann wrote:
I think it is a good idea to switch to xalan-2.6.0 since some more bugs
are fixed in 2.6.0. To get xalan-2.6.0 work in jetty, we can not place
the xalan-2.6.0 in
Nicola Ken Barozzi wrote:
Leo Simons wrote:
...
avalon-framework very rarely doesn't get built by gump. It's the ECM
dependency that's causing the ripples, and the big set of dependencies
ECM has itself.
Since it seems ECM is being put into the freezer anyway, just be
pragmatic and
Sorry, this mail went the wrong path :)
On Wed, 2004-04-07 at 17:20, Rolf Kulemann wrote:
On Wed, 2004-04-07 at 16:19, Rolf Kulemann wrote:
On Wed, 2004-04-07 at 13:56, Michael Wechner wrote:
Rolf Kulemann wrote:
I think it is a good idea to switch to xalan-2.6.0 since some more bugs
Hello,
I'd like to log all Requests so that we can record them for analysis.
So, far the only way I think I can do this is to modify the method
process(..) in org.apache.cocoon. In this method, I thought I could use
a logging component (which has yet to be created) from the component
manager
On 07 Apr 2004, at 16:05, Nicola Ken Barozzi wrote:
Steven Noels wrote:
On 07 Apr 2004, at 11:09, Nicola Ken Barozzi wrote:
The issue is not so technical as it's of indipendence from something
that, in the good and the bad, has not helped Cocoon be built by
Gump for ages now.
As much as I like
On 07.04.2004 14:08, Marc Portier wrote:
with it you wouldn't even need to declare it in your form-definition
since it really only has a purpose for the binding, and actually
never really is a true/valid widget, or is it?
Not necessarily. I have two cases. One overview list of persons where
an
Excuse me if this is a FAQ, but what is a generator implementing the
o.a.c.caching.CacheableProcessingComponent interface expected to return
as the value of the getValidity method, in case the generated content
never changes?
TIA,
Ugo
Ugo Cei wrote:
Excuse me if this is a FAQ, but what is a generator implementing the
o.a.c.caching.CacheableProcessingComponent interface expected to
return as the value of the getValidity method, in case the generated
content never changes?
It can return NOPValidity.SHARED_INSTANCE if you want
Il giorno 08/apr/04, alle 00:18, Upayavira ha scritto:
Ugo Cei wrote:
Excuse me if this is a FAQ, but what is a generator implementing the
o.a.c.caching.CacheableProcessingComponent interface expected to
return as the value of the getValidity method, in case the
generated content never
On 08.04.2004 01:18, [EMAIL PROTECTED] wrote:
ugo 2004/04/07 16:18:48
Added: src/java/org/apache/cocoon/generation CalendarGenerator.java
Log:
A calendar generator. Might be useful for a blog or any site that has
chronologically ordered resources.
What exactly does it do?
On 06.04.2004 17:32, [EMAIL PROTECTED] wrote:
joerg 2004/04/06 08:32:03
Modified:src/blocks/forms/samples/forms form1_template.xml
form1_template_action.xml
Log:
Tim, forget my stupid comment about different styling in and outside of repeaters -
find the
On 05.04.2004 17:19, Vadim Gritsenko wrote:
in the past I was used to:
1) cp blocks.properties local.blocks.properties
2) vi local.blocks.properties
3) uncomment the blocks that I wanted to exclude
Today, I have to go thru a bunch of include and change them from true
to false. Much more
Hi:
I know I am very pushing XUL here. But I really believe this is a
interesting way to follow :-)
Here an interesting article:
http://linuxtoday.com/developer/2004040800426OPSW
Best Regards,
Antonio Gallardo
40 matches
Mail list logo
