portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Evans" <aaronmev...@gmail.com>
Subject Re: svn commit: r469307 [1/3] - in /portals/jetspeed-2/trunk: applications/gems/src/java/org/apache/portals/gems/dojo/ applications/j2-admin/src/java/org/apache/jetspeed/portlets/security/permissions/ applications/j2-admin/src/webapp/WEB-INF/ applica
Date Tue, 31 Oct 2006 14:47:06 GMT
On 10/30/06, smilek@apache.org <smilek@apache.org> wrote:
> Author: smilek
> Date: Mon Oct 30 14:35:55 2006
> New Revision: 469307
> URL: http://svn.apache.org/viewvc?view=rev&rev=469307
> Log:
> Improved management of html <head> content via HeaderResource and HeaderAggregatorImpl.
> Recently added doHeader phase has facilitated a close examination of remaining header
generation problems. This check-in is about addressing the following deficiencies:
> 1) Detection of the addition of duplicate header content is too coarse-grained. For example,
entire script blocks are compared with each other as each is added. Exacerbating this problem
is that each block is the complete definition for an html element to be added to the <head>
(e.g. <script>, <link>, <style>).
> 2) In order to load a toolkit like dojo, each portlet which requires dojo needs to specify
all header content needed to load the basic dojo in addition to any portlet specific header
requirements. Making matters worse, this portlet must deal with the differences in dojo loading
between /portal and /desktop. To date this problem has been mitigated by moving the common
load code to a base class such as AbstractDojoVelocityPortlet.
> 3) Header content must be specified in java code and/or templates (e.g. velocity, jsp).
The template solution further encumbers the effort to detect duplicate header content.
> 4) The ordering of header content is determined by whatever order the portlets get rendered.
> We're writing an entry on this topic to add to the Documentation Guides.
> Steve Milek

are you saying this checkin *solves* the above deficiencies?  Just
curious because I've been doing a lot of thinking around this stuff


To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message