Hi Sylvain,
Sylvain Wallez wrote:
Hmm... do you really need that?
Yep, in my current situation i needed this. I'm not sure why, probably
because we developed custom stylesheets for forms and maybe altered a
bit the default resource uri :)
Simply I thought that since it's workin
Reinhard Poetz skrev:
Torsten Curdt wrote:
On 04.03.2006, at 01:54, Carsten Ziegeler wrote:
Some time ago the support for per sitemap classloaders has been
added to
2.2; this feature is currently disabled (for making the implementation
for blocks easier I guess).
I guess it is just disab
Carsten Ziegeler skrev:
Some time ago the support for per sitemap classloaders has been added to
2.2; this feature is currently disabled (for making the implementation
for blocks easier I guess).
Now the question is, do we want to support this or is this obsolete when
we have the blocks implemen
Ralph Goers wrote:
I am pinging again to see where we stand. AFAIK the only thing we are
waiting for is Sylvain's blessing on Ajax. Also, does Ajax need to be
marked stable since Forms depends on it?
Please wait a few more days (not more, promise!), I'm nearly finished
with the new Ajax stuf
Simone Gianni wrote:
Hi Carsten,
I checked out latest 2.1.X yesterday and had the same problems,
nothing client side (submit on change, other events) worked anymore.
The error was it could not find a lot of dojo related stuff, I just
had to add a match in the sitemap for the dojo javascript :
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> Some time ago the support for per sitemap classloaders has been added to
>> 2.2; this feature is currently disabled (for making the implementation
>> for blocks easier I guess).
>>
>> Now the question is, do we want to support this or is this obsol
Simone Gianni schrieb:
> Hi Carsten,
> I checked out latest 2.1.X yesterday and had the same problems, nothing
> client side (submit on change, other events) worked anymore. The error
> was it could not find a lot of dojo related stuff, I just had to add a
> match in the sitemap for the dojo jav
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> Some time ago the support for per sitemap classloaders has been added to
>> 2.2; this feature is currently disabled (for making the implementation
>> for blocks easier I guess).
>>
>> Now the question is, do we want to support this or is this obsol
Hi,
It looks like the jar is broken on
http://www.ibiblio.org/maven/cocoon/jars/cocoon-forms-2.1.8.jar. When I
use the jar I get the error:
org.apache.avalon.framework.logger.AbstractLogEnabled.access$201(Lorg/apache/cocoon/forms/binding/JXPathBindingManager;)Lorg/apache/avalon/framework/logger/L
Hi Carsten,
I checked out latest 2.1.X yesterday and had the same problems, nothing
client side (submit on change, other events) worked anymore. The error
was it could not find a lot of dojo related stuff, I just had to add a
match in the sitemap for the dojo javascript :
Now they all
Hi,
The Daisy update on the cocoon zone is done.
I have also added some new sitemap reference docs, e.g.
http://cocoon.zones.apache.org/daisy/documentation/sitemap/reference/pipeline_elements/842.html
It's basically a document for each sitemap element, with a short
description, the attributes,
Torsten Curdt wrote:
On 04.03.2006, at 01:54, Carsten Ziegeler wrote:
Some time ago the support for per sitemap classloaders has been added to
2.2; this feature is currently disabled (for making the implementation
for blocks easier I guess).
I guess it is just disabled by default because i
Carsten Ziegeler wrote:
Some time ago the support for per sitemap classloaders has been added to
2.2; this feature is currently disabled (for making the implementation
for blocks easier I guess).
Now the question is, do we want to support this or is this obsolete when
we have the blocks implemen
On 04.03.2006, at 01:54, Carsten Ziegeler wrote:
Some time ago the support for per sitemap classloaders has been
added to
2.2; this feature is currently disabled (for making the implementation
for blocks easier I guess).
I guess it is just disabled by default because it is a new feature
No
Anyone against merging the DefaultTreeBuilder and the SitemapLanguage class?
Currently DTB is abstract and SL is the only sub class of it. And I
think although the general nature of the DTB is to be a general tree
builder solution, the current implementation is not that general. And
the SL will be
Some time ago the support for per sitemap classloaders has been added to
2.2; this feature is currently disabled (for making the implementation
for blocks easier I guess).
Now the question is, do we want to support this or is this obsolete when
we have the blocks implementation soon? In this case
VerifyException "Attempt to split long or double on the stack" in javaflow
--
Key: COCOON-1790
URL: http://issues.apache.org/jira/browse/COCOON-1790
Project: Cocoon
Type: Bug
Components: Blocks
* Max Pfingsthorn:
> sorry for this noise... It was my fault. I didn't release a
> source properly in one of my generators...
Just to be sure: is it a cocoon: source that was missing to be
released? For a file: source, I don't think it makes a difference
to release it or not.
--
Jean-B
Ralph Goers wrote:
> I am pinging again to see where we stand. AFAIK the only thing we are
> waiting for is Sylvain's blessing on Ajax. Also, does Ajax need to be
> marked stable since Forms depends on it?
>
We experienced some strange problems with latest forms as some of our
applications
usin
I am pinging again to see where we stand. AFAIK the only thing we are
waiting for is Sylvain's blessing on Ajax. Also, does Ajax need to be
marked stable since Forms depends on it?
Ralph
* Max Pfingsthorn:
> Okay, for the WebDAVSource, or any Inspectable and Traverseable
> source, you will get an InspectableTraversableCachingSource
> from the CachingSourceFactory. This source will actually put
> SourceProperty objects in a map for its cached response. The
> cached r
* Max Pfingsthorn:
> sorry for this noise... It was my fault. I didn't release a
> source properly in one of my generators...
>
> Jean-Baptiste, maybe you have the same problem?
This is a very good suggestion. Maybe a cocoon: source is not
released. I will double check.
--
Jean-Baptis
On Fri, 2006-03-03 at 11:38 +0100, Jean-Baptiste Quenot wrote:
> Hello,
>
> Can someone with Daisy karma grant me to edit documents? I would
> like to change the « Who we are » page for now.
done, enjoy.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open So
Hi!
Okay, for the WebDAVSource, or any Inspectable and Traverseable source, you
will get an InspectableTraversableCachingSource from the CachingSourceFactory.
This source will actually put SourceProperty objects in a map for its cached
response. The cached response is Serializable, but not the
Hello!
Yes, please, I would like one :)
Thanks!
max
> -Original Message-
> From: David Crossley [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 02, 2006 23:33
> To: dev@cocoon.apache.org
> Subject: Re: Cocoon developers opensource license YourKit
> Java Profiler
>
>
> David Crossley
Dear all,
sorry for this noise... It was my fault. I didn't release a source properly in
one of my generators...
Jean-Baptiste, maybe you have the same problem?
Bye!
max
> -Original Message-
> From: Max Pfingsthorn
> Sent: Thursday, March 02, 2006 13:10
> To: dev@cocoon.apache.org
> S
Hello,
Can someone with Daisy karma grant me to edit documents? I would
like to change the « Who we are » page for now.
Thanks in advance,
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Jean-Baptiste Quenot wrote:
...
Then can you explain the current tasks left to do to have the
blocks framework?
https://issues.apache.org/jira/secure/IssueNavigator.jspa?requestId=12310712
It's not completely up to date. Since we wrote it we have changed from
ECM++ to Spring for Cocoon. Thi
* Reinhard Poetz:
> Jean-Baptiste Quenot wrote:
>
> >* Reinhard Poetz:
> >
> >>Jean-Baptiste Quenot wrote:
> >>
> >>
> >>>And I have a more general question: what concrete usecase and
> >>>existing blocks have motivated the design and development of
> >>>the wiring feature? Do we have several
Jean-Baptiste Quenot wrote:
* Reinhard Poetz:
Jean-Baptiste Quenot wrote:
And I have a more general question: what concrete usecase and
existing blocks have motivated the design and development of
the wiring feature? Do we have several blocks implementing
the same interface?
see h
* David Crossley:
> It looks like the patch was made against the old CVS for Cocoon.
>
> My did you Close, rather than just ask for a new patch?
Because the bug is three years old, there is very little
probability that the contributor still uses Cocoon. That's why I
stated: « Feel fr
* Reinhard Poetz:
> Jean-Baptiste Quenot wrote:
>
> > And I have a more general question: what concrete usecase and
> > existing blocks have motivated the design and development of
> > the wiring feature? Do we have several blocks implementing
> > the same interface?
>
> see http://wiki.ap
Hi,
If nobody minds I'd like to upgrade the Daisy on the cocoon zone this
afternoon, somewhere around 4 pm CET. Since this involves restarting
Daisy, it's better not to edit docs in Daisy around that time. I'll give
a notice when it's done.
Bruno.
--
Bruno Dumon http
Antonio Fiol Bonnín wrote:
Some thoughts (my opinion) about configuration.
1. Environment-related configuration should be banned inside the
webapp directory (or WAR file).
2. Business-related configuration should be inside it.
[...]
Thanks for sharing your ideas! After having some working pro
34 matches
Mail list logo
