Carsten Ziegeler wrote:
So today I think we should host the first versions as a sub project at
Cocoon
What do you mean with sub-project? If it became a sub project, would it have to
go through the incubator then?
and do some marketing for it. This should buy us some users from
outside of
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Thanks Carsten and Jörg! After adding the
org.springframework.web.filter.RequestContextFilter, the reloading classloader
(works like the shielded cl) works for me again.
For some reasons the use of the
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
So today I think we should host the first versions as a sub project at
Cocoon
What do you mean with sub-project? If it became a sub project, would it have
to
go through the incubator then?
No, code donations should go through the
Carsten Ziegeler wrote:
In the last days I converted our FileGenerator from an Avalon based
component to a spring managed bean. With spring we have the advantage
that we don't need a special GeneratorFactory interface anymore. Spring
supports several ways of instantiation which is totally
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
So today I think we should host the first versions as a sub project at
Cocoon
What do you mean with sub-project? If it became a sub project, would it have to
go through the incubator then?
No, code donations should go
Reinhard Poetz wrote:
What's wrong with property injection? (I'm asking because you certainly know
about it ;-) ):
bean name=o.a.c.s.s/mySerializer
property name=mime-type value=text/xml/
/bean
The current sitemap features do not require the component implementation
to have support for
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
What's wrong with property injection? (I'm asking because you certainly know
about it ;-) ):
bean name=o.a.c.s.s/mySerializer
property name=mime-type value=text/xml/
/bean
The current sitemap features do not require the component
Jeremy Quinn wrote:
Hi All
I hope you all had a good Christmas.
Santa's little helpers have been busy working on CForms over the holiday
break :)
Below is a list of changes I have in my local repo, ready to commit. I
would like to get feedback on these changes, in case of dissent, or
Reinhard Poetz wrote:
we could provide an abstract parent bean definition
(http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-child-bean-definitions).
Yes, but this would also mean that all implementations inherit from an
abstract class we provide. This is not a
Carsten Ziegeler skrev:
[EMAIL PROTECTED] wrote:
Author: danielf
Date: Wed Dec 27 08:47:40 2006
New Revision: 490536
URL: http://svn.apache.org/viewvc?view=revrev=490536
Log:
Moving the pipeline implementations to the cocoon-pipeline-impl module. To make
this possible the caching package
Do we already have a block-aware link rewriting transformer in our codebase?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Reinhard Poetz skrev:
Do we already have a block-aware link rewriting transformer in our
codebase?
You can use the LinkRewriterTransformer together with the
BlockPathModule (long time since I tested it though). But it would
probably make sense to have a special purpose transformer for
Daniel wrote:
OK, I can move the xml stuff that I moved to cocoon-xml to
cocoon-pipeline instead. Then later when we pojofy (or springify) the
xml stuff we can move generally useful stuff with few dependencies to
cocoon-xml.
Great and thanks!
Carsten
--
Carsten Ziegeler - Chief Architect
Carsten Ziegeler skrev:
Daniel wrote:
OK, I can move the xml stuff that I moved to cocoon-xml to
cocoon-pipeline instead. Then later when we pojofy (or springify) the
xml stuff we can move generally useful stuff with few dependencies to
cocoon-xml.
Great and thanks!
Done!
/Daniel
On 28 Dec 2006, at 07:38, Carsten Ziegeler wrote:
Hi Jeremy,
this sounds all great to me -
cool :)
but I can't really judge the impact of
your suggested changes.
not until I commit anyway ;)
But I have two questions :)
Is it still possible to use cforms without javascript after your
On 28 Dec 2006, at 09:26, Jeroen Reijn wrote:
Jeremy Quinn wrote:
Hi All
I hope you all had a good Christmas.
Santa's little helpers have been busy working on CForms over the
holiday break :)
Below is a list of changes I have in my local repo, ready to
commit. I would like to get
Hi All
Another question
Currently, when onSubmit Handers are called, they are able to stop
the form submit by returning false. OK so far.
However, if you have multiple handlers and say the middle one returns
false, the ones after it, do not get called at all.
Is this the right
On 28 Dec 2006, at 12:01, Jeremy Quinn wrote:
And does the new stuff better support multiple forms on one page. I
think there are some problems with the current onsubmit handlers when
there is more than one form.
Yes, I had to change the API for adding submit handlers to allow
for more
Hi, I've been wanting to ask this question in one form or another for
at least the last year, but never gotten around to it until now... at
various points I've scanned the archives for the early discussions
about real blocks, and skimmed discussions btwn. Daniel and others on
the dev list as
Jeremy Quinn wrote:
I have not tested how cforms works without javascript for a long time
TBH.
Me neither, but I know that there are several projects (trying to use)
using cforms without any javascript at all (for accessibility).
So as long as it doesn't get harder with your changes, I'm fine
Hmm,
I'm not sure - I haven't used onSubmit handlers so far as they did not
work with multiple forms :) So we are currently using our own handler
implementation. We mainly use them for client-site prevalidation like
checking for required fields etc. In this case I think it makes sense to
stop
I think the xconf for these input-modules was in the wrong location. The
current configuration files are a little bit confusing and spread
throughout our code base.
Anyways, xconf files are only read from the classpath; I guess the input
modules you are refering to are configured in the
On 28 Dec 2006, at 15:16, Carsten Ziegeler wrote:
Hmm,
I'm not sure - I haven't used onSubmit handlers so far as they did not
work with multiple forms :) So we are currently using our own handler
implementation.
Well hopefully this will be solved :)
We mainly use them for client-site
I'm working on moving the treeprocessor and its dependencies (including
the core package in the cocoon-core module) to the cocoon-sitemap-impl
module. Would it be possible for you to not work on cocoon-core for the
next hour or so?
/Daniel
[EMAIL PROTECTED] skrev:
Author: cziegeler
Date:
Daniel Fagerstrom wrote:
I'm working on moving the treeprocessor and its dependencies (including
the core package in the cocoon-core module) to the cocoon-sitemap-impl
module. Would it be possible for you to not work on cocoon-core for the
next hour or so?
Sure, I'll wait with my changes
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
I'm working on moving the treeprocessor and its dependencies (including
the core package in the cocoon-core module) to the cocoon-sitemap-impl
module. Would it be possible for you to not work on cocoon-core for the
next hour or so?
Jeremy Quinn wrote:
If I understand you correctly, I think I would prefer all pre-
validation to occur even if there are validation errors found,
otherwise user needs to fix-submit, fix-submit etc. to 'discover' the
errors one by one. I would rather see all validation errors in one go.
On 28 Dec 2006, at 16:12, Carsten Ziegeler wrote:
Jeremy Quinn wrote:
If I understand you correctly, I think I would prefer all pre-
validation to occur even if there are validation errors found,
otherwise user needs to fix-submit, fix-submit etc. to 'discover' the
errors one by one. I would
I just created a new webapp and block using the archetypes from trunk and I
get the same error when using the Jetty-Eclipse-Plugin to run the webapp:
java.lang.IllegalStateException: No thread-bound request found: Are you
referring to request attributes outside of an actual web request? If you
Philipp Zerelles wrote:
I just created a new webapp and block using the archetypes from trunk and I
get the same error when using the Jetty-Eclipse-Plugin to run the webapp:
java.lang.IllegalStateException: No thread-bound request found: Are you
referring to request attributes outside of an
Well, I created the eclipse project using mvn eclipse:eclipse. Then I
imported it into my workspace (btw, I ony use the webapp now with the
SitemapServlet) and configured the Jetty Launcher to use my Jetty 5.1.12
installation (that defaults to Servlet 2.4, too) and set the webapp root
to
On 28.12.2006 09:36, Carsten Ziegeler wrote:
What's wrong with property injection?
The current sitemap features do not require the component implementation
to have support for a mime-type (or a label), so they don't need to have
a property for that.
We could use properties for that, with the
Mark Lundquist wrote:
Hi, I've been wanting to ask this question in one form or another for at
least the last year, but never gotten around to it until now... at
various points I've scanned the archives for the early discussions about
real blocks, and skimmed discussions btwn. Daniel and
Daniel Fagerstrom skrev:
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
I'm working on moving the treeprocessor and its dependencies
(including the core package in the cocoon-core module) to the
cocoon-sitemap-impl module. Would it be possible for you to not work
on cocoon-core for the
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Seem like a good idea. But in that case I think that we don't should use
cocoon as default name in some of the paths. The name of the module
should also be something more descriptive than spring.
Hmm, yes, I agree. Any suggestions? (I'm not
Online report :
http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/64/buildId/1327
Build statistics:
State: Error
Previous State: Ok
Started at: Fri, 29 Dec 2006 00:04:47 +
Finished at: Fri, 29 Dec 2006 00:04:49 +
Total
Online report :
http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/63/buildId/1325
Build statistics:
State: Error
Previous State: Ok
Started at: Fri, 29 Dec 2006 00:04:30 +
Finished at: Fri, 29 Dec 2006 00:04:31 +
Total
Mark Lundquist skrev:
Hi, I've been wanting to ask this question in one form or another for at
least the last year, but never gotten around to it until now... at
various points I've scanned the archives for the early discussions about
real blocks, and skimmed discussions btwn. Daniel and
[EMAIL PROTECTED] skrev:
Author: cziegeler
Date: Thu Dec 28 23:33:07 2006
New Revision: 490937
URL: http://svn.apache.org/viewvc?view=revrev=490937
Log:
Adjust to new structure
Modified:
39 matches
Mail list logo
