You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ferdinand Soethe <fe...@apache.org> on 2005/07/31 11:58:54 UTC
Use Cocoon Portlets rather than views?
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?
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.
--
Ferdinand Soethe
Re: Use Cocoon Portlets rather than views?
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> 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?
>>
>>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.
>
>
> This is a very interesting topic. I went to Carsten's talk
> about Cocoon Portal at ApacheCon. Being a Cocoon application
> it seemed that it could be integrated easily.
>
> Johannes had a quick experiment at ApacheCon and i think
> talked to Carsten a bit.
>
> I wonder if the way forward is an integration of portals
> and our "views", i.e. the portal does some of the work
> and our views does the rest.
This is what I suspect. Portals are way advanced in terms of integration
of content and config systems. However, from a cursory glance at the
portals I think that views has much to bring to the party with respect
to themes (take a look at the HTML code of a portal generated page on
the demo below, you'll quickly see what I mean.
> There is an online demo at:
> http://cocoon.zones.apache.org/demos/release/samples/blocks/portal/
> and Carsten's session slides are at
> http://wiki.apache.org/apachecon/Eu2005OnlineSessionSlides
Ross
Re: Use Cocoon Portlets rather than views?
Posted by Carsten Ziegeler <cz...@apache.org>.
David Crossley schrieb:
> 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?
>>
>>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.
>
>
> This is a very interesting topic. I went to Carsten's talk
> about Cocoon Portal at ApacheCon. Being a Cocoon application
> it seemed that it could be integrated easily.
>
> Johannes had a quick experiment at ApacheCon and i think
> talked to Carsten a bit.
>
> I wonder if the way forward is an integration of portals
> and our "views", i.e. the portal does some of the work
> and our views does the rest.
>
> There is an online demo at:
> http://cocoon.zones.apache.org/demos/release/samples/blocks/portal/
> and Carsten's session slides are at
> http://wiki.apache.org/apachecon/Eu2005OnlineSessionSlides
>
If you need more information or want to discuss the topic, just let me
know. I'm not familiar with the latest forrest and views...
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Use Cocoon Portlets rather than views?
Posted by David Crossley <cr...@apache.org>.
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?
>
> 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.
This is a very interesting topic. I went to Carsten's talk
about Cocoon Portal at ApacheCon. Being a Cocoon application
it seemed that it could be integrated easily.
Johannes had a quick experiment at ApacheCon and i think
talked to Carsten a bit.
I wonder if the way forward is an integration of portals
and our "views", i.e. the portal does some of the work
and our views does the rest.
There is an online demo at:
http://cocoon.zones.apache.org/demos/release/samples/blocks/portal/
and Carsten's session slides are at
http://wiki.apache.org/apachecon/Eu2005OnlineSessionSlides
David
Re: Use Cocoon Portlets rather than views?
Posted by Ross Gardler <rg...@apache.org>.
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
Re: Use Cocoon Portlets rather than views?
Posted by Ross Gardler <rg...@apache.org>.
Nicola Ken Barozzi wrote:
> Johannes Schaefer wrote:
> ...
>
>>* The portal uses a configuration hierarchy:
>> 1. define coplets
>> 2. define instances
>> (may use coplets multiple times)
>> 3. define the layout
>
>
> How does it define layout?
I'm going to move this mail and the one you are replying to into the
other thread. My reasoning is that the subject is less worrying to those
actually working on views at present.
I'll reply there.
For those reading in the archives see
http://marc.theaimsgroup.com/?l=forrest-dev&m=112282643816153&w=2
Ross
Re: Use Cocoon Portlets rather than views?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Johannes Schaefer wrote:
...
> * The portal uses a configuration hierarchy:
> 1. define coplets
> 2. define instances
> (may use coplets multiple times)
> 3. define the layout
How does it define layout?
One more thing that comes to mind... Cocoon portal-coplets seem like a
perfect way to define what /content/ is to be in a page.
It seems to me that it starts lacking when I need to insert pieces of
functionality, as they may have to touch the whole page and filter it.
IOW a portal is an excellent - user configurable - <xinclude> mechanism,
but views are not only about that.
I mean, views are basically a page-templating system. Can a portal be
defined as a page-templating system?
Still many questions and no good answer...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Use Cocoon Portlets rather than views?
Posted by Johannes Schaefer <jo...@uidesign.de>.
Ferdinand Soethe schrieb:
> 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.
I ran a Cocoon-Portal instance on my computer and an
independent Forrest one. Then I changed the config files
until I got "http://localhost:forrest/body-index.html"
into a coplet window. Finally I had some success.
This was the weekend right after the ApacheCon. Had no
time to fiddle around more, I'm back to work (BTW: a
Cocoon project). Sorry for the delay, I wanted to learn
more before posting ...
I noted some things, though.
* As Ross said, the layout seems to be completely table-based
and Forrest already has left this behind. I did not try to
change the styling, though.
* For Forrest content to go into the portal I had to strip the
<html> and <body> tags. The portal integrates content as-is
into the final page an did not like multiple <html>s inside
too much (although it didn't blew up).
* I created a new sub-sitemap only for forrest, which is pretty
easy in the portal framework (once you know where and what to
change; it resides below the coplet folder, like 'docs').
* Forrest does not output xhtml as all the abc2xhtml.xsl
stylesheets are saying. body-*.html is not even valid XML
(no single root tag), let alone html.
* The portal uses a configuration hierarchy:
1. define coplets
2. define instances
(may use coplets multiple times)
3. define the layout
* Changes in these files (at least no. 2) sometimes required a
restart of Cocoon/Portal to take effect which is rather
annoying (maybe it's time to install tomcat ;-)
* Thorsten uses some simple xdoc-files for some of the content
and I'm quite sure it would be no big deal to pass them
through Forrest before output.
I'm lacking behind on Forrest:views (still), so I cannot
compare the two.
I'm willing to have a closer look, best with support by Carsten
who seems to read the thread (e.g. the frequent restarts) -- as
time allows.
Cheers
Johannes
Ferdinand Soethe schrieb:
> 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?
>
> 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.
>
> --
> Ferdinand Soethe
>
>
--
User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg
Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99
Geschäftsstelle: User Interface Design GmbH * Lehrer-Götz-Weg 11 * D-81825 München
www.uidesign.de
Buch "User Interface Tuning" von Joachim Machate & Michael Burmester
www.user-interface-tuning.de