Stefano Mazzocchi wrote:
The more I go around talking about what cocoon is, the more I think that cforms should not be a block.
Why don't you want it to be a block?
We had some discussion related to documentation and moving out blocks from core where we agreed about dividing the blocks in three categories:
/cocoon/blocks/core /cocoon/blocks/supported /cocoon/blocks/unsupported
to make it obvious for users (and our selves ;) ), what level of community involvement a certain block has. Then forms, template and javaflow should be part of blocks/core to show there special status. For the rest of the blocks the default place is "unsupported" until we have voted them into "supported". And it is important to notice the difference between supported/unsupported and stable/unstable. A block that no one care about will be extremely stable in the sense that it doesn't change. While a block that many people care about will change as all the use cases and testing will lead to new insights. So as always it is community involvement that counts.
IMO core should be as lean as possible and contain the execution engine, common infrastructure, components and interfaces, but nothing more.
Having forms in a block allows for a separate release cycle.
This also requires the 'template' system to reside in the core.
So, here is my proposal:
1) move cforms in core
Absolutely a core block but not into core
2) stop considered 'alpha' and decide to release it when cocoon 2.2 is ready (how far are we from stabilizing cforms anyway?)
+1
3) rename jxtemplate as CTemplate and moving it in the core as well
+1 for CTemplate but core block rather than core.
/Daniel
