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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
