Proposal to extend the Portlet API to include doHeader()

[Randy Watler <wa...@wispertel.net>]

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

Re: Proposal to extend the Portlet API to include doHeader()

[Randy Watler <wa...@wispertel.net>]

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

Re: Proposal to extend the Portlet API to include doHeader()

[Shinsuke SUGAYA <sh...@yahoo.co.jp>]

Hi Randy,

I think it's interesting solution. I hope that JSR 286 has it or the
like.

My question is, if user deploy JetspeedGenericPortlet to other portal,
does it work? On Portal other than J2, I expect that JetspeedGenericPortlet
can work though doHeader() do nothing.

Since this change affects my portlets, it would be great if you can
provide me the interface info for doHeader() you are thinking.

Thanks,
  shinsuke

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
> 
> 

--------------------------------------
TSUKAME EIKOU! KAGAYAKE EGAO!
Yahoo! JAPAN JPC OFFICIAL PARTNER INTERNET PORTAL SITE
http://pr.mail.yahoo.co.jp/wintergames/

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