portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Watler <wat...@wispertel.net>
Subject Re: Proposal to extend the Portlet API to include doHeader()
Date Tue, 07 Mar 2006 14:16:15 GMT
After pondering ways to avoid parsing the header content contributed by 
each portlet, I have come up with this approach based around comparing 
HTML tag ids. Here is an example of content returned to J2 using the 
doHeader() API:

<meta name="keywords" content="header tag id example">
<link id="com.myco.styles" type="text/css" 
href="/myportletapp/styles/custom.css">
<script id="dojo.toolkit.config" type="text/javascript">var djConfig = 
{...};</script>
<script id="dojo.toolkit.library-2.2" type="text/javascript" 
src="/dojo/dojo.js">
<script id="dojo.toolkit.require.event.all" 
type="text/javascript">dojo.require('dojo.event.*');</script>
<script id="dojo.toolkit.require.io" 
type="text/javascript">dojo.require('dojo.io');</script>

If a single portlet specified this information, it would simply be 
included verbatim. If more than one portlet specified similar script and 
link tags as above, the two ordered lists of tags identified by the id 
fields would be merged in a way that preserved the ordering of the tags 
while eliminating duplicates.

Ids would be formatted in a way similar to maven ids: 
<group-id>.<artifact-id>-<version-number>. This way, we can always 
choose the highest version of duplicate scripts. Otherwise, the first 
definition found of any particular tag would be used. Any script, link, 
style, meta or other header tag without an id would always be included. 
J2 layout portlets would also participate in the doHeader() protocols 
and thus would define an initial set of header content tags.

The parsing involved does not appear to be too intensive, but we could 
use Neko if it comes to that. Using a content based approach as is done 
in the rest of the Portlet API requires some sort of parsing. However, 
this allows portlets to utilize familiar content generation techniques 
including Velocity and JSPs to define header content.

Thoughts?

Randy

Randy Watler wrote:
> Gang,
>
> As we delve into richer client side applications, the need to manage 
> header content for portlets becomes more pronounce. We currently have 
> the header-resource component and it does a good job at what it can do 
> from the jetspeed context. However,  we now we have a requirement  to 
> generate header content from velocity templates as we do for view, 
> edit, help, etc. modes using the velocity bridges portlets.
>
> I attempted to extend the existing header resource component by 
> setting up its own velocity engines, but ran into a brick wall when I 
> tried to execute templates/toolboxes in the portlet app context. There 
> still may be a way to make this approach work, but it was getting ugly 
> and I started looking for another way. After speaking with David, he 
> suggested extending the Portlet API by adding a doHeader() API. After 
> thinking about it overnight, it does seem very attractive.
>
> Apparently, there was some discussion concerning adding doHeader to 
> the Portlet API for JSR-286. I am not sure what the status of that 
> proposal is. If we add doHeader() to JetspeedGenericPortlet, we no 
> doubt will be departing from the standard API. The use of the 
> header-resource component creates an identical portability problem, so 
> I dont feel that doHeader() should be viewed as somehow worse from an 
> API pollution perspective.
>
> The purpose of this API is to allow portlets to contribute header 
> content into page. However, there are many more restrictions on what 
> individual portlets should be allowed to insert in this shared scope. 
> One of the biggest constraints: duplicate tags and javascript 
> declarations/invocations should be stripped so that only one minimal 
> set of header content elements and scripts is added to the header. The 
> current header-resource component limits what can be inserted in the 
> header to enforce these restrictions; arbitrary text cannot be inserted.
>
> It is not clear that we can support arbitrary text inclusion from 
> velocity templates and yet maintain the constraints above. This is 
> still being kicked around: velocity templates and doHeader() seem to 
> offer a powerful implementation paradigm, but a limited java API based 
> approach can avoid parsing header content in an attempt to create a 
> minimal header. Any ideas here are welcome! Early middle ground 
> approaches might include HTML tags with well known ids or using an 
> import like API that includes templates inline during later aggregation.
>
> Comments, ideas, or other input welcome... just wanted to get the 
> discussions started here on the email list.
>
> Randy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
>


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


Mime
View raw message