Peter Donald wrote:
On Tue, 26 Nov 2002 15:31, Peter Donald wrote:

On Tue, 26 Nov 2002 11:04, Stefano Mazzocchi wrote:

I agree with you that ECM is crappy code. And you know that in order to
implement Cocoon Blocks, we'll need a much more modern (and thought-out)
container and that in order to be able to do that, we might even allow
some back-incompatible changes (for something like Cocoon 3.0) where it
does make sense to break compatibility.

BTW - it may be best not to name them "Blocks". Phoenix already has the notion of blocks which is vastly different from what Cocoon proposes to use the term for. It would confusing to name two different concepts with identical names. Given that Phoenix (and it's predecessor) has been using the term since before I was involved in Avalon it may be best to rename Cocoon blocks to something else so as to avoid confusion from users.
Suggestions;

* Cocoon Packs (foo.pak or foo.pax or foo.cpk)
* Cocoon Archives (foo.car)
* Cocoon Modules (foo.mod)
* Cocoon Libraries (foo.clb)
* Cocoon Bags (foo.bag) (as in Bean Bags)
* Cocoon Tins (foo.tin) * Cocoon Boxs (foo.box)

It's (almost) too late, we already have a blocks dir in CVS, and have been talking a lot about "blocks".
Probably the extension will be ".cob"

Anyway, it seems that "Phoenix Blocks" are probably to be superceded by "Avalon Components/Services", so it should not be a big problem.
Till now it has not been, since Cocoon and Phoenix do not (yet) overlap.

--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to