Stefano Mazzocchi wrote:
I had the same reaction at first, and then it accurred to me that if we went down the path of having optional code and optional sitemap in blocks, not only people are likely to keep them separate (ending up with 'sitemap blocks' and 'code blocks') but that would force us to reinvent the maven wheel for code blocks.
I'm not actually 100% of how this separation is going to work in real life, but I'm willing to sit back and watch how far along we can go while keeping things separate, because making them unified I fear was one of the reasons why blocks have been so hard of a problem to attack.
At the end, we might end up understanding that we need to reinvent the maven wheel, but I really hope not.
So, I suggest you to follow me in being a little more hopeful about it, sit back and watch the show and just trust the community in its collective wisdom.
What do you mean by "reinvent the maven wheel"? If my boss ever lets me have some time to work on Cocoon, one of the first things I'd like to do is to try to introduce maven into the Cocoon build. IMO, this has needed to happen for quite a while regardless of what happens with blocks. We've been "reinventing" maven for far too long.
I'm not trying to get in the way. It is just that my company will be using the Cocoon Portal to manage the layout of all our products. I really like the block concept, but if I can't apply it to the portal I just don't see the value of it. The Portal block is primarily a bunch of components - many of which are not sitemap components. They would actually need to be provided, or packaged in, the Portal block, but configured by the block that implements the application. In addition, it would make sense to have individual portlets packaged in their own blocks. These could be JSR-168 portlets, which can contain JSPs and/or Java code, or they could be Cocoon Portlets - which are primarily sitemaps.
In short, "real blocks" could be a huge win for dealing with the Cocoon Portal, if they have the needed support.
Ralph
