Geoff Howard wrote:
Reinhard Poetz wrote:
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
The source-copy action already exists in
o.a.c.acting.CopySourceAction, and the o.a.c.c.flow.util.PipelineUtil
class could easily be generalized to any source, and not only cocoon:.
Thanks for your
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
The source-copy action already exists in
o.a.c.acting.CopySourceAction,
and the o.a.c.c.flow.util.PipelineUtil class could easily be
generalized
to any source, and not only cocoon:.
Thanks for your answer and confirming that this would
Reinhard Poetz wrote:
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
The source-copy action already exists in
o.a.c.acting.CopySourceAction,
and the o.a.c.c.flow.util.PipelineUtil class could easily be
generalized
to any source, and not only cocoon:.
Thanks for your answer and confirming
Darn. Meant for this to go to the list, not to you directly.
-Original Message-
From: Ralph Goers
To: 'Joerg Heinicke '
Sent: 1/27/2004 9:06 PM
Subject: RE: [proposal] Cleaning up our component library
I realise I am fairly new to Cocoon and my opinion probably doesn't
carry as much
Le Mercredi, 28 jan 2004, à 02:40 Europe/Zurich, Joerg Heinicke a écrit
:
One problem often mentioned is that Cocoon provides to many
possibilities to achieve some goals. Cocoon's flexibility ends where
it is more confusing than helpful. Therefore I want to propose to
remove/deprecate the
On Wed, 2004-01-28 at 08:43, Ralph Goers wrote:
snip/
We'd love to use Woody (aka Cocoon Forms), but if it can be used without
FlowScript it isn't obvious. So we will be using the
SimpleFormTransformer etc., for the forseeable future.
Woody doesn't require flowscript. While flowscript
On Jan 28, 2004, at 8:43 AM, Ralph Goers wrote:
We'd love to use Woody (aka Cocoon Forms), but if it can be used
without
FlowScript it isn't obvious.
Woody and FlowScript should be totally independent from each other.
Much of the fun stuff lately has been done in the JS utility library,
but
Bertrand Delacretaz wrote:
Le Mercredi, 28 jan 2004, à 02:40 Europe/Zurich, Joerg Heinicke a écrit :
[...]
...I propose to deprecate those components in 2.1 and to remove them
in 2.2...
In cases where this just needs sitemap changes, no problem. But if
deprecation requires code changes to
On 28.01.2004 10:55, Andreas Hartmann wrote:
b) maybe add an option to throw an exception when such components are
used (strict deprecation)
This sounds very useful. There are some non-IDE users in
our community who aren't that much aware of deprecation.
Could it be switched on/off globally?
On 28.01.2004 07:52, Bertrand Delacretaz wrote:
One problem often mentioned is that Cocoon provides to many
possibilities to achieve some goals. Cocoon's flexibility ends where
it is more confusing than helpful. Therefore I want to propose to
remove/deprecate the components that are no longer
From: Joerg Heinicke
One problem often mentioned is that Cocoon provides to many
possibilities to achieve some goals. Cocoon's flexibility
ends where it
is more confusing than helpful. Therefore I want to propose to
remove/deprecate the components that are no longer the correct way to
Joerg Heinicke wrote:
So alltogether:
a) Components that are just renamed or replaced with only sitemap
changes (FileGenerator = XMLGenerator, DirectoryGenerator =
TraversableGenerator (or however it is called ;-) ), StreamGenerator =
XMLGenerator + ModuleSource) are deprecated in 2.1
Carsten Ziegeler wrote:
Joerg Heinicke wrote:
So alltogether:
a) Components that are just renamed or replaced with only sitemap
changes (FileGenerator = XMLGenerator, DirectoryGenerator =
TraversableGenerator (or however it is called ;-) ), StreamGenerator =
XMLGenerator + ModuleSource)
Ralph Goers [EMAIL PROTECTED] writes:
Our
environment has special security concerns that just won't
allow a scripting language - or even JSPs or XSPs for that
matter.
Ok, I'll bite; why single out scripting languages and dynamically
produced pages? What about dynamically compiled Java?
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Joerg Heinicke wrote:
So alltogether:
a) Components that are just renamed or replaced with only sitemap
changes (FileGenerator = XMLGenerator, DirectoryGenerator =
TraversableGenerator (or however it is called ;-) ), StreamGenerator
=
Bruno Dumon wrote:
On Wed, 2004-01-28 at 08:43, Ralph Goers wrote:
snip/
We'd love to use Woody (aka Cocoon Forms), but if it can be used without
FlowScript it isn't obvious. So we will be using the
SimpleFormTransformer etc., for the forseeable future.
Woody doesn't require flowscript.
From: Carsten Ziegeler
Joerg Heinicke wrote:
So alltogether:
a) Components that are just renamed or replaced with only sitemap
changes (FileGenerator = XMLGenerator, DirectoryGenerator =
TraversableGenerator (or however it is called ;-) ),
StreamGenerator =
XMLGenerator +
for
that. I really don't want to have to reimplement a bunch of stuff.
-Original Message-
From: Geoff Howard [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 28, 2004 7:45 AM
To: [EMAIL PROTECTED]
Subject: Re: [proposal] Cleaning up our component library
What about doing weak deprecation
Geoff Howard wrote:
Vadim Gritsenko wrote:
And we should only move things into the deprecated part if there is a
usable alternative. IMHO, using flow instead of a transformer isn't
really
an alternative as the overhead is way to much (just my opinion here).
-1 to replacing of
: [proposal] Cleaning up our component library
I mean that there is already an action written to copy sources, if I'm
not mistaken, which can copy one sosurce to another. Combined with
cocoon protocol and all other protocols you can do a lot with it. But
I'm not saying that I've analyzed all use
Joerg Heinicke [EMAIL PROTECTED] proposes:
snip on discussion about components to be deprecated/
I propose to
deprecate
those components in 2.1 and to remove them in 2.2.
Yes please! As Cocoon grows it gets harder and harder to see the real
direction it is heading as long as it continues
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 28, 2004 12:30 AM
To: [EMAIL PROTECTED]
Subject: Re: [proposal] Cleaning up our component library
On Jan 28, 2004, at 8:43 AM, Ralph Goers wrote:
We'd love to use Woody (aka Cocoon Forms), but if it can be used
without
FlowScript it isn't
Le Mercredi, 28 jan 2004, à 11:52 Europe/Zurich, Joerg Heinicke a écrit
:
...With our deprecated block we have another mean to lead the user to
the new components. When it's excluded the application will just not
work. But I don't know if this is true for 2.2 and real blocks too...
hmm...I
On 28.01.2004 16:44, Geoff Howard wrote:
So alltogether:
a) Components that are just renamed or replaced with only sitemap
changes (FileGenerator = XMLGenerator, DirectoryGenerator =
TraversableGenerator (or however it is called ;-) ), StreamGenerator
= XMLGenerator + ModuleSource) are
One problem often mentioned is that Cocoon provides to many
possibilities to achieve some goals. Cocoon's flexibility ends where it
is more confusing than helpful. Therefore I want to propose to
remove/deprecate the components that are no longer the correct way to
go, that are misleading by
25 matches
Mail list logo
