Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42ECCF04.7050300@apache.org>
Date: Sun, 31 Jul 2005 14:15:48 +0100
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: Use Cocoon Portlets rather than views?
References: <196944769.20050731115854@soethe.net>
In-Reply-To: <196944769.20050731115854@soethe.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ferdinand Soethe wrote:
> At ApacheCon Johannes, after listening to the presentation on Cocoon
> portlets, raised the question if views were not re-inventing the wheel
> with Cocoon portlets (I hope I remember the name right) already
> offering a similar functionality.
> 
> Ross said that he wanted to take a look at the latest version in
> Cocoon and see if and how far we are actually duplicating
> functionality.
> 
> Ross, are you still going to comment on this? Can anybody else please
> comment? Are we in fact reinventing the wheel here?

See my other mail on this. I basically said I am willing to help 
evaluate the cocoon portal as a views implementation, but that I am not 
going to do it unless I have the backing of the community, without that 
backing I would be concerned about splintering the community on a views 
implementation debate. If enough of us see the merit then I'm willing to 
do the work.

However, I should point out that I have always believed the Cocoon 
portal engine to be the ideal vehicle for this work, I'm not sure if 
this makes me a good person to evaluate it or not since I have never had 
a strong enough itch to follow through on my mails - Thorsten has had 
and has done a great job.

For context on my opinion here are a few quotes from my mails in the 
archives (oldest first):

"Clearly this is not general enough to meet the needs of this RT [this 
was the first RT for what is now known as forrest:views]. So how
should we go about generalising things? One suggestion would be to use
the portal view defined by the portal engine in Cocoon (see
http://cocoon.apache.org/2.1/developing/portal/profiles.html#The+Portal+View), 

this would save us having to redesign the layout wheel"

from - http://marc.theaimsgroup.com/?l=forrest-dev&m=109138015520138&w=2

---

"I'm still wondering if we shouldn't simply adopt the approach used in
the Cocoon Portal Engine for defining the layout within skinconf.xml.
This would enable us to leverage other parts of the portal engine to
manage the layout - a web based editor for page layout. It could also
provide us with a set of information "nuggets" as they were called in
the original RT."

from - http://marc.theaimsgroup.com/?l=forrest-dev&m=109144923819949&w=2

---

"Views are taking Forrest very close to a Portal like environment. Yet 
we have not, at any time considered using JSR-168 stuff in the design of
templates.

I'm not suggesting that Forrest becomes yet another Portal 
implementation, but then again, maybe I am. How easy/difficult/.sensible
would it be to resuse Portal stuff i views?

(Cocoon has a pretty solid Portal implementation already if we can
leverage that...)"

from - http://marc.theaimsgroup.com/?l=forrest-dev&m=112124832731477&w=2

---

Here's an interesting quote form Thorsten (which convinces me it should 
be explored and that even Thorsten - who is closest to the views code, 
would not get upset if we considered switching his views implementation 
to the Cocoon Portal engine):

"I was at a client yesterday and he showed me his own portlet 
implementation for cocoon (no java spec. one, but  more a modified 
cocoon portal one) and I showed him views.

Guess what, we developed similar solutions without knowing from each 
other. Yes views gives us a portal. Even right now, but I agree we need 
a more generic contract. My client used
*.xmap as businessHelper that where linked with a portlet.

I mean we can allow each contract to resolve the model trough a contract 
specific sitemap. Since yesterday I cannot stop thinking about it. It 
follows the KISS approach which rocks. :)"

from http://marc.theaimsgroup.com/?l=forrest-dev&m=112076836220429&w=2

> With all the work going into implementing views, testing and
> documenting them right now I'd like to see such a discussion happen
> rather soon.

+1 - thanks for raising this and giving it attention via its own thread

Ross