You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Thorsten Scherler <th...@apache.org> on 2005/07/31 21:50:45 UTC
Re: Quick evaluation of Cocoon Portal Engine as forrest:views
implementation
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 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
>