forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Quick evaluation of Cocoon Portal Engine as forrest:views implementation
Date Sun, 31 Jul 2005 21:41:30 GMT
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
> 


Mime
View raw message