Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <42EDD056.4090002@uidesign.de>
Date: Mon, 01 Aug 2005 09:33:42 +0200
From: Johannes Schaefer <johannes.schaefer@uidesign.de>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: Quick evaluation of Cocoon Portal Engine as forrest:views
 implementation
References: <42ECF8BD.6040900@apache.org>
In-Reply-To: <42ECF8BD.6040900@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

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