You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ross Gardler <rg...@apache.org> on 2005/07/31 18:13:49 UTC
Quick evaluation of Cocoon Portal Engine as forrest:views implementation
This is only a very quick evaluation of the Cocoon Portal Engine as a
possible forrest:views implementation. It is in no way exhaustive and I
have not done any real experiments with code. This last point is *very*
important. I have not evaluated how practicle it is to utilise the
Cocoon portal engine to create a *static* rendering of a Forrest site.
I've been working from the Portal demo in Cocoon [1], Carstens slides
form ApacheConEU2005 [2] and the portal documentation [3]
Layout Definition
-----------------
Nearest equivalent in forrest:views is the *.fv files.
The portal engine excels here. It provides a web based interface for
defining your layout, this can be used in a dynamic environment to allow
users to have their own unique layout.
Advantages I see of the portal engine over forrest:views include:
- tried and tested config language
- configs can be stored anywhere (such as XML files, LDAP or other
repositories)
- clean and simple layout config
- deep nesting is possible
What I am not sure about at this stage is if we can have per directory,
per document or per doctype layout definitions. However, since the
layout is retrieved from a standard Cocoon pipeline I doubt it would be
difficult to move the forrest:views solution into the portlet engine.I
note one of the bullets in Carstens presentation was "Layout engine can
be used without additional Portal functionality" - need to investigate this.
Coplets
--------
Nearest equivalent in forrest:views is forrest:templates
The portal engine is JSR-168 compliant (the demo includes the pluto [4]
test suite of portlets). WSRP support is "coming real soon". This gives
us access to a growing number of stnadards based portlets.
Looking at how a portlet is defined it should be trivial to migrate our
30+ contracts to portlets.
Advantages that I see of coplets over forrest:contracts include:
- simpler config
- individual buffering of coplet content (prevents the whole page
breaking if an individual coplet is broken)
- individual error handling for each coplet
- configrable timeouts for coplet data
- configuration overriding capabilities
- configured rendering of individual coplets (i.e. create different
formats from a single coplet instance)
- uses placeholders for coplets - in a dynamic environment page will
render even if still waiting for some coplet data
Themes
------
This looks like the weakest part of the Cocoon Portal engine and where
forrest:views can improve things considerably. At present much of the
style information is embedded in the resulting HTML page. This is not
acceptable for a Forrest solution.
Most of the style information is embedded within the layout definition
file. I think we would have to extend the portal engine to have
behaviour like that provided by forrest:hooks so that the structure of
the resulting portal page can be easily skinned by CSS. Looking at the
current layout config files this does not look like it is complex
(remember this is only a cursory evaluation, not a proposal at this stage)
NOTE: there is a bullet in one of Carstens slides that says "change the
skin". I've not discovered more about this yet.
Tools Framework
---------------
This is an area that is still under development, however, it is a stated
goal of the project to create a tools framework for managing portals. It
is likely that this framework could be used to build customer focussed
tools for developing forrest sites.
Conclusion
----------
My cursory evaluation makes me think that we should eplore this further,
but before I spend more time on this I would like to have some community
feedback.
References
----------
[1]
http://cocoon.zones.apache.org/demos/release/samples/blocks/portal/portal
[2]
http://www.osoco.org/pdfs/ace2005-onehourportalwithcocoon.pdf
[3]
http://cocoon.apache.org/2.1/developing/portal/index.html
[4]
http://portals.apache.org/pluto/
Re: Quick evaluation of Cocoon Portal Engine as forrest:views
implementation
Posted by Thorsten Scherler <th...@apache.org>.
On Sun, 2005-07-31 at 23:36 +0200, Nicola Ken Barozzi wrote:
> Thorsten Scherler wrote:
> > When you mean using "Cocoon Portlets rather then views" and dropping the
> > whole view implementation, then no. There is more to view then the scope
> > of portlets.
> ...
>
> It seems to me that you are a bit on the defensive side, and this mail
> does not seem to be constructive.
>
You are right, I will play around with the Cocoon Portal, before I will
enter this discussion again. ;-)
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Posted by Ross Gardler <rg...@apache.org>.
Nicola Ken Barozzi wrote:
> My first reaction to the coplet stuff was "Forrest is not a portal!",
> but then I tried to understand better, and it seems to make more sense.
>
> I'm not saying that I want it, but I agree with Ross that there is some
> interesting stuff there.
:-)
I'm not saying I want it either. I'm simply saying that we should
explore it.
> Maybe reading this could help in understanding why Forrest as a portal
> could make sense:
>
> http://marc.theaimsgroup.com/?l=forrest-dev&m=101431895118349
Yes. I agree this is an interesting thread (that takes me back a very
long time too ;-)
It is great to see how close we are too the original concept, but also a
shame that we are so far from the implementing the complete wish list.
Ross
Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Thorsten Scherler wrote:
> When you mean using "Cocoon Portlets rather then views" and dropping the
> whole view implementation, then no. There is more to view then the scope
> of portlets.
...
It seems to me that you are a bit on the defensive side, and this mail
does not seem to be constructive.
My first reaction to the coplet stuff was "Forrest is not a portal!",
but then I tried to understand better, and it seems to make more sense.
I'm not saying that I want it, but I agree with Ross that there is some
interesting stuff there.
Maybe reading this could help in understanding why Forrest as a portal
could make sense:
http://marc.theaimsgroup.com/?l=forrest-dev&m=101431895118349
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> When you mean using "Cocoon Portlets rather then views" and dropping the
> whole view implementation, then no.
That is not what my mail was about (that was the subject of a different
mail). Please see the subject of my thread. It is about using the portal
engine as an *implementation* of forrest:views.
> There is more to view then the scope
> of portlets.
The Cocoon Portal Engine is more than just a Portlet container.
> The idea is not to limit views (and
> contracts) to a specific implementation. Cocoon portlets can be *one*
> implementation but there should/could be as well other.
OK, given that the idea is "not to limit views (and contracts) to a
specific implementation." then shouldn't we focus more on a clean
specification of views rather than expending effort on creating a new
implementation. Do we really want to reinvent the wheel when we have the
Cocoon Portal Engine ready to go? I'm undecided, I'm looking for a
community view on this.
In other words, if the actual implementation engine is irrelevant to
forrest:views then wouldn't we be better going with an almost complete
implementation (Cocoon portal engine) rather than creating a whole new one?
> Can the cocoon portal use CLI?
As I said in the original mail, I am not sure. It is designed as a
dynamic app so we may have to make some modifications.
>>I've been working from the Portal demo in Cocoon [1], Carstens slides
>>form ApacheConEU2005 [2] and the portal documentation [3]
>>
>>Layout Definition
>>-----------------
>>
>>Nearest equivalent in forrest:views is the *.fv files.
...
> My idea is to use forrest:views for producing [5] and I reckon that is a
> great idea. I see [5] as implementation of our views. I mean
> forrest:views are transformed into [5] when requested in a portal.
The docs you reference are for version 1 of the Cocoon Portal (it was
called the portal framework). This is indicated in a Note at the start
of the document. I am proposing we use the portal engine (see my
original links, in particular [3]).
> A pdf document would not need a portal configuration and engine just
> another implementation of views. The format independent concept of views
> is the important point.
I understand that the portal engine is not currently used to create
different output formats, but neither is forrest:views (as they
currently stand).
I cannot see anything in the portal engine configs that would prevent us
from reusing them for other formats. However, as the forrest:views
configs currently stand they cannot be used for any format that does not
have the concept of a head and a body as found in HTML.
I think I must be missing something about your vision for forrest:views.
Can you explain to us how forrest:views are more "format independant"
than the current portal config system?
> I do not see the following advantages from the "Layout Definition" over
> forrest:views:
>
> - clean and simple layout config
> I consider forrest:views way simpler and cleaner (or at least not more
> complicated).
OK, we have to agree to differ there. I find forrest:views verbose and
complex. I do believe they can be simplified considerably though. So
this is a matter of discussion once we decide which way to go.
> Having [5]:
> <coplet id="personalize" position="1" number="1">
> <resource uri="financecoplet-personalize.xml"/>
> <configuration>
> <mandatory>true</mandatory>
> <sizable>true</sizable>
> <active>true</active>
> </configuration>
> <title>Personalisieren</title>
> <status>
> <visible>true</visible>
> <size>max</size>
> </status>
> <content>..the coplet content...</content>
> </coplet>
>
> We have:
>
>><forrest:contract name="content-feeder">
>> <forrest:properties contract="content-feeder">
>> <forrest:property name="content-feeder"
>>nugget="get.nugget.feeder">
>> <url>/feeds/somefeed.xml</url>
>> </forrest:property>
>> </forrest:properties>
>></forrest:contract>
No, that is not a valid comparison since you are showing a version 1
config file, not a version 2. Version 2 would look something like:
<coplet-data id="somefeed" name="standard">
<title>An RSS Feed</title>
<coplet-base-data>URICoplet</coplet-base-data>
<attribute>
<name>uri</name>
<value>cocoon://feeds/somefeeds.xml</value>
</attribute>
</coplet-data>
In th Cocoon Portal Engine (as opposed to Portal Framework) there is
another config file that is the equivalent of a *.fv file see [3] and
linked pages.
> I agree we can learn a lot of [5] but it should be seen as a portal
> implementation of forrest:views. I can reuse a contract in a different
> environment that not have to be based on Cocoon Portlets but I still can
> use the same DSL configuration language to configure the environment.
It is not [5] that we are considering, but [3]. The important thing is
there are already many lessons from the work you reference implemented
in the implementation I am exploring.
> - deep nesting is possible
> That is as well possible with forrest:views.
OK
> The main advantage of forrest:views is that is not limited to portlets.
Neither is the Cocoon Portal engine. It has the concept of Coplets which
are almost identical to forrest:contracts. Portlets lets are just *one*
type of Coplet, others are XSL tranformations (i.e. forrest:templates),
java classes, XML content and many others.
> x output format - one configuration. That is the slogan of
> forrest:views.
See above. Please explain how forrest:views is more independant than the
portal engine config?
>>What I am not sure about at this stage is if we can have per directory,
>>per document or per doctype layout definitions. However, since the
>>layout is retrieved from a standard Cocoon pipeline I doubt it would be
>>difficult to move the forrest:views solution into the portlet engine.I
>>note one of the bullets in Carstens presentation was "Layout engine can
>>be used without additional Portal functionality" - need to investigate this.
>>
>
>
> Not moved but write a transformation for forrest:views to [5].
Creating a tranformation is a possible solution (not to the portal
framework [5] though, to the Portal Engine [3]).
Please explain what the advantage of this is over using the Portal
Engine configs in Forrest? (with the theming enhanvements you created in
forrest:views)
>>Coplets
>>--------
>>
>>Nearest equivalent in forrest:views is forrest:templates
>>
>
>
> <forrest:contracts/>
Yes
>>The portal engine is JSR-168 compliant (the demo includes the pluto [4]
>>test suite of portlets). WSRP support is "coming real soon". This gives
>>us access to a growing number of stnadards based portlets.
>>
>
>
> Actually the PMC agreed that forrest do not want to focus on being a
> JSR-168 compliant portal.
I do not recall that discussion, but I have no doubt that this would be
the conclusion. This thread is not about turning Forrest into a Portal
engine, it is about using the Cocoon Portal Engine as an implementation
of forrest:views.
To decide if this is a good idea we need to discover what the portal
engine gives us that views does not and vice-verse. That is the
intention of this thread.
The fact that the Cocoon Portal Engine is JSR-168 compliant is a benefit
in that we can utilise the growing range of portlets. However, as I note
above, Coplets are not limited to just portlets. They can be simple XSL
transofrmations, i.e. forrest:contracts
>>Advantages that I see of coplets over forrest:contracts include:
>>
>>- simpler config
>
>
> No, I do not see that they are simpler.
...
>>- individual buffering of coplet content (prevents the whole page
>>breaking if an individual coplet is broken)
>>- individual error handling for each coplet
>>- configrable timeouts for coplet data
>>- configuration overriding capabilities
>>- configured rendering of individual coplets (i.e. create different
>>formats from a single coplet instance)
>>- uses placeholders for coplets - in a dynamic environment page will
>>render even if still waiting for some coplet data
>>
>
>
>
> Yes that is very nice but they are only special contacts.
That is my point, they are special contracts that are already
implemented. Most of these features are non-trivial. Using the portal
engine as an implementation we would get them all for free.
>>Themes
>>------
>>
>>This looks like the weakest part of the Cocoon Portal engine and where
>>forrest:views can improve things considerably. At present much of the
>>style information is embedded in the resulting HTML page. This is not
>>acceptable for a Forrest solution.
>>
>>Most of the style information is embedded within the layout definition
>>file. I think we would have to extend the portal engine to have
>>behaviour like that provided by forrest:hooks so that the structure of
>>the resulting portal page can be easily skinned by CSS. Looking at the
>>current layout config files this does not look like it is complex
>>(remember this is only a cursory evaluation, not a proposal at this stage)
>
>
>>NOTE: there is a bullet in one of Carstens slides that says "change the
>>skin". I've not discovered more about this yet.
>>
>
>
> I have to have a closer look into this part, but I reckon Cocoon Portal
> may consider cooperate on our configuration format (forrest:views).
Bingo - that is *exactly* what I am suggesting, although I would phrase
it as "cooperate on our configuration format", i.e without calling it
forrest:views.
My reasoning is simple: since the portal engine is more powerful than
views in terms of layout and views is more powerful in terms of themes
we should take the best of both and improve both Forrest and the Cocoon
Portal Eninge at the same time, thereby creating a larger developer base.
>>Conclusion
>>----------
>>
>>My cursory evaluation makes me think that we should eplore this further,
>>but before I spend more time on this I would like to have some community
>>feedback.
>>
>
>
> IMO we should not exclusively focus the development of forrest:views
> onto cocoon portal. We have to cooperate the best we can. Following
> David comment:
>
>>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.
>
> It should be
> "Using forrest:views for configuring Cocoon Portlets" and not like
> suggested "Use Cocoon Portlets rather than views?".
Again, that was a different thread. Please see the subject of this mail.
I'm saying the same as David.
I believe we are closer in vision than you may think, but I suspect you
are feeling that someone is trying to throw out your "baby". I assure
you that is not the case. I simply want to consider using the Cocoon
Portal Engine as an *implementation* of forrest:views, how tat would
work is still up for discussion.
Ross
>>References
>>----------
>>
>>[1]
>>http://cocoon.zones.apache.org/demos/release/samples/blocks/portal/portal
>>
>>[2]
>>http://www.osoco.org/pdfs/ace2005-onehourportalwithcocoon.pdf
>>
>>[3]
>>http://cocoon.apache.org/2.1/developing/portal/index.html
>>
>>[4]
>>http://portals.apache.org/pluto/
>>
>>
>>
>
> [5]http://cocoon.apache.org/2.1/developing/webapps/portal.html#The
> +Layout+Profile
>
Re: Quick evaluation of Cocoon Portal Engine as forrest:views
implementation
Posted by Thorsten Scherler <th...@apache.org>.
When you mean using "Cocoon Portlets rather then views" and dropping the
whole view implementation, then no. There is more to view then the scope
of portlets.
Cocoon Portlets should be usable within the forrest:views *.fv as
forrest:contracts. The *.fv will be the meta configuration of all
included forrest:contracts. The idea is not to limit views (and
contracts) to a specific implementation. Cocoon portlets can be *one*
implementation but there should/could be as well other.
forrest:views is more a concept (interface) rather then an specific
implementation. The forrest:contracts that we have right now would be
another implementation besides portlets. ...but there should not become
necessarily portlets themselves like you suggest.
On Sun, 2005-07-31 at 17:13 +0100, Ross Gardler wrote:
> This is only a very quick evaluation of the Cocoon Portal Engine as a
> possible forrest:views implementation. It is in no way exhaustive and I
> have not done any real experiments with code. This last point is *very*
> important. I have not evaluated how practicle it is to utilise the
> Cocoon portal engine to create a *static* rendering of a Forrest site.
>
Can the cocoon portal use CLI?
> I've been working from the Portal demo in Cocoon [1], Carstens slides
> form ApacheConEU2005 [2] and the portal documentation [3]
>
> Layout Definition
> -----------------
>
> Nearest equivalent in forrest:views is the *.fv files.
>
> The portal engine excels here. It provides a web based interface for
> defining your layout, this can be used in a dynamic environment to allow
> users to have their own unique layout.
>
> Advantages I see of the portal engine over forrest:views include:
>
> - tried and tested config language
> - configs can be stored anywhere (such as XML files, LDAP or other
> repositories)
> - clean and simple layout config
> - deep nesting is possible
>
My idea is to use forrest:views for producing [5] and I reckon that is a
great idea. I see [5] as implementation of our views. I mean
forrest:views are transformed into [5] when requested in a portal.
A pdf document would not need a portal configuration and engine just
another implementation of views. The format independent concept of views
is the important point.
I do not see the following advantages from the "Layout Definition" over
forrest:views:
- clean and simple layout config
I consider forrest:views way simpler and cleaner (or at least not more
complicated).
Having [5]:
<coplet id="personalize" position="1" number="1">
<resource uri="financecoplet-personalize.xml"/>
<configuration>
<mandatory>true</mandatory>
<sizable>true</sizable>
<active>true</active>
</configuration>
<title>Personalisieren</title>
<status>
<visible>true</visible>
<size>max</size>
</status>
<content>..the coplet content...</content>
</coplet>
We have:
> <forrest:contract name="content-feeder">
> <forrest:properties contract="content-feeder">
> <forrest:property name="content-feeder"
> nugget="get.nugget.feeder">
> <url>/feeds/somefeed.xml</url>
> </forrest:property>
> </forrest:properties>
> </forrest:contract>
I agree we can learn a lot of [5] but it should be seen as a portal
implementation of forrest:views. I can reuse a contract in a different
environment that not have to be based on Cocoon Portlets but I still can
use the same DSL configuration language to configure the environment.
- deep nesting is possible
That is as well possible with forrest:views.
The main advantage of forrest:views is that is not limited to portlets.
x output format - one configuration. That is the slogan of
forrest:views.
>
> What I am not sure about at this stage is if we can have per directory,
> per document or per doctype layout definitions. However, since the
> layout is retrieved from a standard Cocoon pipeline I doubt it would be
> difficult to move the forrest:views solution into the portlet engine.I
> note one of the bullets in Carstens presentation was "Layout engine can
> be used without additional Portal functionality" - need to investigate this.
>
Not moved but write a transformation for forrest:views to [5].
> Coplets
> --------
>
> Nearest equivalent in forrest:views is forrest:templates
>
<forrest:contracts/>
> The portal engine is JSR-168 compliant (the demo includes the pluto [4]
> test suite of portlets). WSRP support is "coming real soon". This gives
> us access to a growing number of stnadards based portlets.
>
Actually the PMC agreed that forrest do not want to focus on being a
JSR-168 compliant portal. That is not our main focus but it could be
easily done via the forrest:views language *layer*. We can support
Cocoon portlet implementation via forrest:views but we still are open
for other implementation
>
> Looking at how a portlet is defined it should be trivial to migrate our
> 30+ contracts to portlets.
>
IMO we should not do this because forrest is not a portal.
> Advantages that I see of coplets over forrest:contracts include:
>
> - simpler config
No, I do not see that they are simpler.
> - individual buffering of coplet content (prevents the whole page
> breaking if an individual coplet is broken)
> - individual error handling for each coplet
> - configrable timeouts for coplet data
> - configuration overriding capabilities
> - configured rendering of individual coplets (i.e. create different
> formats from a single coplet instance)
> - uses placeholders for coplets - in a dynamic environment page will
> render even if still waiting for some coplet data
>
Yes that is very nice but they are only special contacts.
> Themes
> ------
>
> This looks like the weakest part of the Cocoon Portal engine and where
> forrest:views can improve things considerably. At present much of the
> style information is embedded in the resulting HTML page. This is not
> acceptable for a Forrest solution.
>
> Most of the style information is embedded within the layout definition
> file. I think we would have to extend the portal engine to have
> behaviour like that provided by forrest:hooks so that the structure of
> the resulting portal page can be easily skinned by CSS. Looking at the
> current layout config files this does not look like it is complex
> (remember this is only a cursory evaluation, not a proposal at this stage)
> NOTE: there is a bullet in one of Carstens slides that says "change the
> skin". I've not discovered more about this yet.
>
I have to have a closer look into this part, but I reckon Cocoon Portal
may consider cooperate on our configuration format (forrest:views).
> Tools Framework
> ---------------
>
> This is an area that is still under development, however, it is a stated
> goal of the project to create a tools framework for managing portals. It
> is likely that this framework could be used to build customer focussed
> tools for developing forrest sites.
>
> Conclusion
> ----------
>
> My cursory evaluation makes me think that we should eplore this further,
> but before I spend more time on this I would like to have some community
> feedback.
>
IMO we should not exclusively focus the development of forrest:views
onto cocoon portal. We have to cooperate the best we can. Following
David comment:
> 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.
It should be
"Using forrest:views for configuring Cocoon Portlets" and not like
suggested "Use Cocoon Portlets rather than views?".
salu2
> References
> ----------
>
> [1]
> http://cocoon.zones.apache.org/demos/release/samples/blocks/portal/portal
>
> [2]
> http://www.osoco.org/pdfs/ace2005-onehourportalwithcocoon.pdf
>
> [3]
> http://cocoon.apache.org/2.1/developing/portal/index.html
>
> [4]
> http://portals.apache.org/pluto/
>
>
>
[5]http://cocoon.apache.org/2.1/developing/webapps/portal.html#The
+Layout+Profile
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Posted by Johannes Schaefer <jo...@uidesign.de>.
Another thing I've missed to mention
(this is taken from Carsten's presentation and the
demo portal)
* there is an event mechanism that allows interaction
between coplets, e.g. moving a picture from a list
into another coplet.
Don't know how Forrest could use this but it seems to
be a powerful mechanism.
Johannes
Ross Gardler schrieb:
> Ross Gardler wrote:
>
>> Johannes Schaefer wrote:
>>
>>> Once again, Ross was faster to post and I responded
>>> to the first thread rather than reading on.
>>>
>>> This subject line is mcuh better than the other one
>>> (I would not see a competition but reduction of workload
>>> and re-use of code on both sides!).
>>>
>>> Ross' evaluation confirms what I've found out. It should
>>> be easy to integrate Forrest content but the skinning is
>>> weak.
>>
>>
>>
>> Thanks Johannes, it is good to hear that the docs give the same
>> impression as actually playing with the code.
>
>
> I'm moving Johannes mail from another thread here so that we can discuss
> it in more detail in this thread. Here is Johannes mail, unedited:
>
> Johannes Schaefer wrote:
>>
>> 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
>
>
--
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
Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Posted by Carsten Ziegeler <cz...@apache.org>.
Nicola Ken Barozzi schrieb:
> Carsten Ziegeler wrote:
>
>
>>But I just wanted to add that each and every portal has its own
>>description mechanism, Jetspeed uses its psml, Cocoon has the layout
>>description etc. In the case of the cocoon portal, even this language is
>>pluggable, so you can use your own one if you want. (I hope noone shouts
>>FS now :) )
>
>
> Actually no, because this is exactly what we want to do, so it's useful
> ATM :-)
>
> Just a hint: how to plug it in?
>
There is a component for it: the ProfileLS (Profile load/save - lame
name, I know). The current implementation uses castor to read the xml
files, in fact it uses a castor component which reads the xml and
converts them to objects.
Now you can either write your own ProfileLS, or use a different mapping
component.
HTH
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Ross Gardler schrieb:
>
>>Nicola Ken Barozzi wrote:
>>
>>>Here I read: http://portals.apache.org/jetspeed-2/psml.html
>>>
>>>"page layout is not a part of the Java Portlet Standard API"
>>
> Due to time constraints I wasn't able to follow all of these discussions
> - sorry.
Reading this mail though it seems like it's the right suggestion at the
right time. ;-)
> But I just wanted to add that each and every portal has its own
> description mechanism, Jetspeed uses its psml, Cocoon has the layout
> description etc. In the case of the cocoon portal, even this language is
> pluggable, so you can use your own one if you want. (I hope noone shouts
> FS now :) )
Actually no, because this is exactly what we want to do, so it's useful
ATM :-)
Just a hint: how to plug it in?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Posted by Carsten Ziegeler <cz...@apache.org>.
Ross Gardler schrieb:
> Nicola Ken Barozzi wrote:
>>Here I read: http://portals.apache.org/jetspeed-2/psml.html
>>
>> "page layout is not a part of the Java Portlet Standard API"
>
Due to time constraints I wasn't able to follow all of these discussions
- sorry.
But I just wanted to add that each and every portal has its own
description mechanism, Jetspeed uses its psml, Cocoon has the layout
description etc. In the case of the cocoon portal, even this language is
pluggable, so you can use your own one if you want. (I hope noone shouts
FS now :) )
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Posted by Ross Gardler <rg...@apache.org>.
Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
>
>>>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?
>>
>>Full details in [1]. In short you define a series of rows and columns.
>>As both myself and Johannes observed the potential for theming in the
>>Portal Engine is limited, this rows/columns concept is one cause of
>>this. Forrest:views is far superior in its theming. The portal engine
>>skin system looks very similar to our "old fashioned" skinning (see [2])
>>
>>I think that we would want to replace the skinning system with the
>>forrest:views approach (disclaimer: I have not yet discussed this with
>>any Portal devs and have not looked in detail at how realistic this is)
>
>
> Another portal engine with it's theming support explained:
>
> http://www.javalobby.org/articles/liferay/
This site clearly illustrates the strength of forrest:views over a
portal layout descriptor. Notice that the layout of all the pages are
the same, it is only the look and feel that has changed. Now read on...
>>> > 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.
>
> ...
>
>>> > I mean, views are basically a page-templating system. Can a portal be
>>> > defined as a page-templating system?
>>
>>I believe so, furthermore, I believe utilising the portal engine will
>>save us much development effort (I repeat my disclaimer, I have not yet
>>looked under the hood or played with the code - this is a *belief* not
>>an statement of fact).
>
>
> IMV a portal is a dynamic content *aggregator*, rather than a templating
> system, and in this role it will certainly help our efforts.
Yes, which is exactly the purpose of the *views* part of forrest:views,
i.e. strip away away the theme stuff.
> Here I read: http://portals.apache.org/jetspeed-2/psml.html
>
> "page layout is not a part of the Java Portlet Standard API"
What isn't apparent from your single line extract is that this document
describes the page structure language used by jetspeed. In other words
it describes their equivalent to the *.fv files.
The big difference between portal layout languages and the forrest:views
language is that the portal languages define a *fixed* layout whereas
forrest:views define a page structure rather than a layout. This enables
a further separation of concerns:
- the look and feel (the theme) of a forrest:views defined page to be
under the control of the layout designer (the CSS designer for HTML output)
- the definition of the source of content to be aggregated in a page is
under the control of the site designer
- the definition of actual content is under the control of the content
editor
> Now I understand where views can mutually fit in.
>
> Some extra info on Jetspeed layout and decorators:
>
> http://portals.apache.org/jetspeed-2/layouts.html
> http://portals.apache.org/jetspeed-2/decorators.html
Yes - lets play a game, can everyone spot the similarities with
forrest:views?
>
>
> ...
>
>>[1]
>>http://cocoon.apache.org/2.1/developing/portal/portal-block.html#Configuring+the+arrangement+of+the+defined+Coplets
>>
>>[2]
>>http://cocoon.apache.org/2.1/developing/portal/portal-block.html#Create+a+new+skin+for+your+portal
>
>
Ross
Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ross Gardler wrote:
>> 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?
>
> Full details in [1]. In short you define a series of rows and columns.
> As both myself and Johannes observed the potential for theming in the
> Portal Engine is limited, this rows/columns concept is one cause of
> this. Forrest:views is far superior in its theming. The portal engine
> skin system looks very similar to our "old fashioned" skinning (see [2])
>
> I think that we would want to replace the skinning system with the
> forrest:views approach (disclaimer: I have not yet discussed this with
> any Portal devs and have not looked in detail at how realistic this is)
Another portal engine with it's theming support explained:
http://www.javalobby.org/articles/liferay/
>> > 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.
...
>> > I mean, views are basically a page-templating system. Can a portal be
>> > defined as a page-templating system?
>
> I believe so, furthermore, I believe utilising the portal engine will
> save us much development effort (I repeat my disclaimer, I have not yet
> looked under the hood or played with the code - this is a *belief* not
> an statement of fact).
IMV a portal is a dynamic content *aggregator*, rather than a templating
system, and in this role it will certainly help our efforts.
Here I read: http://portals.apache.org/jetspeed-2/psml.html
"page layout is not a part of the Java Portlet Standard API"
Now I understand where views can mutually fit in.
Some extra info on Jetspeed layout and decorators:
http://portals.apache.org/jetspeed-2/layouts.html
http://portals.apache.org/jetspeed-2/decorators.html
...
> [1]
> http://cocoon.apache.org/2.1/developing/portal/portal-block.html#Configuring+the+arrangement+of+the+defined+Coplets
>
> [2]
> http://cocoon.apache.org/2.1/developing/portal/portal-block.html#Create+a+new+skin+for+your+portal
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
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?
Full details in [1]. In short you define a series of rows and columns.
As both myself and Johannes observed the potential for theming in the
Portal Engine is limited, this rows/columns concept is one cause of
this. Forrest:views is far superior in its theming. The portal engine
skin system looks very similar to our "old fashioned" skinning (see [2])
I think that we would want to replace the skinning system with the
forrest:views approach (disclaimer: I have not yet discussed this with
any Portal devs and have not looked in detail at how realistic this is)
> > 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.
Yes, this is the main reason I like the idea of using the portal engine
as a forrest:views implementation. Coplets are not *just* portlets. They
can be JSR-168 portlets (WSRP coming soon) but they can also be a java
class, an XML file, a XSL template or pretty much anything you want them
to be.
forrest:contracts are (at present) only XSL transformations. This does
not allow us to utilise the full power of Cocoon in contracts.
For example when a contract defines /content/ (i.e. the feeder contract)
it uses an XSL template to insert an xi:include into the document. This
is then processed by Cocoon to include the content. In other words it is
*implemented* in exactly the same way as if we insert xi:include
directly into the src document. Since Cocoon cannot cache xi:include
content this creates a major performance problem.
> > 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.
yes
> > I mean, views are basically a page-templating system. Can a portal be
> > defined as a page-templating system?
I believe so, furthermore, I believe utilising the portal engine will
save us much development effort (I repeat my disclaimer, I have not yet
looked under the hood or played with the code - this is a *belief* not
an statement of fact).
> > Still many questions and no good answer...
Lets keep discussing
Ross
[1]
http://cocoon.apache.org/2.1/developing/portal/portal-block.html#Configuring+the+arrangement+of+the+defined+Coplets
[2]
http://cocoon.apache.org/2.1/developing/portal/portal-block.html#Create+a+new+skin+for+your+portal
Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Posted by Ross Gardler <rg...@apache.org>.
This mail was a reply from Nicola in another thread to the mail from
Johanes that I moved here. It is unedited here, I will reply in a moment.
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?
>
>
> 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...
>
Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> Johannes Schaefer wrote:
>
>> Once again, Ross was faster to post and I responded
>> to the first thread rather than reading on.
>>
>> This subject line is mcuh better than the other one
>> (I would not see a competition but reduction of workload
>> and re-use of code on both sides!).
>>
>> Ross' evaluation confirms what I've found out. It should
>> be easy to integrate Forrest content but the skinning is
>> weak.
>
>
> Thanks Johannes, it is good to hear that the docs give the same
> impression as actually playing with the code.
I'm moving Johannes mail from another thread here so that we can discuss
it in more detail in this thread. Here is Johannes mail, unedited:
Johannes Schaefer wrote:
>
> 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
Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Posted by Ross Gardler <rg...@apache.org>.
Johannes Schaefer wrote:
> Once again, Ross was faster to post and I responded
> to the first thread rather than reading on.
>
> This subject line is mcuh better than the other one
> (I would not see a competition but reduction of workload
> and re-use of code on both sides!).
>
> Ross' evaluation confirms what I've found out. It should
> be easy to integrate Forrest content but the skinning is
> weak.
Thanks Johannes, it is good to hear that the docs give the same
impression as actually playing with the code.
Ross
Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Posted by Johannes Schaefer <jo...@uidesign.de>.
Once again, Ross was faster to post and I responded
to the first thread rather than reading on.
This subject line is mcuh better than the other one
(I would not see a competition but reduction of workload
and re-use of code on both sides!).
Ross' evaluation confirms what I've found out. It should
be easy to integrate Forrest content but the skinning is
weak.
Cheers
Johannes
Ross Gardler schrieb:
> Layout Definition
> -----------------
>
> Nearest equivalent in forrest:views is the *.fv files.
>
> The portal engine excels here. It provides a web based interface for
> defining your layout, this can be used in a dynamic environment to allow
> users to have their own unique layout.
>
> Advantages I see of the portal engine over forrest:views include:
>
> - tried and tested config language
> - configs can be stored anywhere (such as XML files, LDAP or other
> repositories)
> - clean and simple layout config
> - deep nesting is possible
>
>
> What I am not sure about at this stage is if we can have per directory,
> per document or per doctype layout definitions. However, since the
> layout is retrieved from a standard Cocoon pipeline I doubt it would be
> difficult to move the forrest:views solution into the portlet engine.I
> note one of the bullets in Carstens presentation was "Layout engine can
> be used without additional Portal functionality" - need to investigate
> this.
>
> Coplets
> --------
>
> Nearest equivalent in forrest:views is forrest:templates
>
> The portal engine is JSR-168 compliant (the demo includes the pluto [4]
> test suite of portlets). WSRP support is "coming real soon". This gives
> us access to a growing number of stnadards based portlets.
>
>
> Looking at how a portlet is defined it should be trivial to migrate our
> 30+ contracts to portlets.
>
> Advantages that I see of coplets over forrest:contracts include:
>
> - simpler config
> - individual buffering of coplet content (prevents the whole page
> breaking if an individual coplet is broken)
> - individual error handling for each coplet
> - configrable timeouts for coplet data
> - configuration overriding capabilities
> - configured rendering of individual coplets (i.e. create different
> formats from a single coplet instance)
> - uses placeholders for coplets - in a dynamic environment page will
> render even if still waiting for some coplet data
>
> Themes
> ------
>
> This looks like the weakest part of the Cocoon Portal engine and where
> forrest:views can improve things considerably. At present much of the
> style information is embedded in the resulting HTML page. This is not
> acceptable for a Forrest solution.
>
> Most of the style information is embedded within the layout definition
> file. I think we would have to extend the portal engine to have
> behaviour like that provided by forrest:hooks so that the structure of
> the resulting portal page can be easily skinned by CSS. Looking at the
> current layout config files this does not look like it is complex
> (remember this is only a cursory evaluation, not a proposal at this stage)
>
> NOTE: there is a bullet in one of Carstens slides that says "change the
> skin". I've not discovered more about this yet.
>
> Tools Framework
> ---------------
>
> This is an area that is still under development, however, it is a stated
> goal of the project to create a tools framework for managing portals. It
> is likely that this framework could be used to build customer focussed
> tools for developing forrest sites.
>
> Conclusion
> ----------
>
> My cursory evaluation makes me think that we should eplore this further,
> but before I spend more time on this I would like to have some community
> feedback.
>
> References
> ----------
>
> [1]
> http://cocoon.zones.apache.org/demos/release/samples/blocks/portal/portal
>
> [2]
> http://www.osoco.org/pdfs/ace2005-onehourportalwithcocoon.pdf
>
> [3]
> http://cocoon.apache.org/2.1/developing/portal/index.html
>
> [4]
> http://portals.apache.org/pluto/
>
>
>
>
--
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