Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <31DF72A980E5D511B48C000102BD868503EA821C@calexc01.diginsite.com>
From: Ralph Goers <Ralph.Goers@digitalinsight.com>
To: "'dev@cocoon.apache.org'" <dev@cocoon.apache.org>
Subject: RE: [VOTE] Woody scratchpad area
Date: Thu, 12 Feb 2004 14:24:06 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

Yes, I do appreciate that there is a status associated with the blocks and
perhaps I shouldn't be so harsh.  However, I have seen folks in the users
list saying that Woody is the recommended approach for forms handling.  How
can an unstable block be the recommended approach?  I've also seen questions
about whether woody is stable and being answered with "Yes".  If so, it
shouldn't be marked as unstable and things should be locked down.

This is somewhat off-topic from my previous post but, as I've said before,
we have looked at woody and have not made the move yet - we are still using
the simple forms stuff.  We like what we see, but so much of the examples
documentation is geared towards flow that we have a hard time separating the
two.  We won't be using flowscript so we really need "Cocoon Forms" to be
completely separate from it.  The major stumbling block was in the areas of
Woody Bindings - the only provided solution seems to require flowscript.
I'm sure I'll revisit this and perhaps provide the solution when it pops to
the top of my list of things to do.

Ralph

 -----Original Message-----
From: 	Joerg Heinicke [mailto:joerg.heinicke@gmx.de] 
Sent:	Thursday, February 12, 2004 2:14 PM
To:	dev@cocoon.apache.org
Subject:	Re: [VOTE] Woody scratchpad area

On 12.02.2004 22:04, Ralph Goers wrote:

> Frankly, I don't believe Woody should have been in 2.1 as a block - it
> should have been in the scratchpad.  The number of fundamental changes
that
> have been made to it clearly indicate that it wasn't stable when 2.1.0 was
> released.  It should never be tolerated that something that is "released"
> (i.e. in core or in a block) is allowed to have its interface or
fundamental
> behavior change from one minor release to the next.  It could have been
> moved from the scratchpad into a block at a minor release when it was
deemed
> ready.

IMO you are wrong here to a certain extend. We introduced the blocks to 
have development independent on the core. Therefore we also introduced 
the status of a block, which can be stable, unstable or deprecated at 
the moment (see the gump descriptor in the Cocoon root dir). This gump 
descriptor is transformed into the file blocks.properties with the hint 
on stable and unstable (but all are included by default). But at latest 
at build time you get a warning about the status if it is unstable and 
what it means. So IMO nobody can complain about any changes for an 
unstable block.

Joerg