I need to go double-check the portlet spec, but my current understanding is 
that the portlet spec does not provide any way for portlets to contribute to 
the head content of a page!  (Does this sound like a common occurrence in JCP 
"standards"?)

The Appendix E of the spec http://www.jcp.org/en/jsr/detail?id=168 is relevant 
here:

<snip>
Features Deferred to Future Releases

The following are some of the features that would be considered in future 
versions of the
Portlet Specification. The technical details of these features would be 
resolved by the
5 Expert Group of the corresponding JSR.
* Portlet filters
* Inter-portlet, event style, communication
* Allow portlets to produce and influence markup outside of the portlet fragment
</snip>

Notice the very last one there.  That kinda sums it up.  (Some would say that, 
as a result, Portlet's a la this spec, suck.)

Here are other relevant parts of the spec:

<snip>
Portlets do not have access to the following functionality provided by servlets:
* Setting the character set encoding of the response
* Setting HTTP headers on the response
* The URL of the client request to the portal
</snip>

<snip>
Portlets generating HTML fragments must not use the following tags: base, body,
iframe, frame, frameset, head, html and title.

Portlets generating XHTML and XHTML-Basic fragments must not use the following
tags: base, body, iframe, head, html and title.
</snip>

<snip>
Within their content, portlets may include elements that must be unique within 
the whole
portal page. JavaScript functions and variables are an example of this 

The getNamespace method must provide the portlet with a mechanism that ensures 
the
uniqueness of the returned string in the whole portal page.  For example, the
getNamespace method would return a unique string that could be prefixed to a
JavaScript variable name within the content generated by the portlet, ensuring 
its
uniqueness in the whole page. The getNamespace method must return the same 
value if
invoked multiple times within a render request.
</snip>

Still, for those odd cases where we control the entire page, how can I link in 
the .js and other stuff.  I don't mind, for example, having it part of all our 
portal pages.  I.e., is there a way to statically link to the relevant .js 
files as-is that would work, or must parts be processed by the 
Script-processing tools provided by Tapestry?

Thanks, 

Ezra Epstein 

-----Original Message-----
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 02, 2006 6:24 PM
To: Tapestry users
Subject: Re: Portlets on Tapestry 4.1

Ok, I think I'm a little out of my element here.

I can't honestly say I understand the day to day sort of development patterns 
that people use with Tapestry portlets.

Is there an equivalent idea to something containing each page? (ie something 
that handles stylesheets/ etc  ?)

Rather than trying to pull what I think is the right way out of my arse, can 
the community help me out a little here? ;)

I do have one specific IRender "bean" sort of class that the @Shell component 
delegates the work of rendering the tapestry/dojo/browser debug configuration 
includes to. It can be found here:
http://tapestry.apache.org/tapestry4.1/tapestry-framework/apidocs/org/apache/tapestry/dojo/AjaxShellDelegate.html
.

If the functionality this provides sounds somewhat palatable I can try 
refactoring the naming a little bit to eliminate the verbage of "Shell".
(I'd like to remove AJAX as well...)

On 8/2/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
>
> Hmm...Good question. I will answer with a documentation page.
>
>
> On 8/2/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
> >
> > We want to move to 4.1 for our portlets.  Reading up I find:
> >
> > "By default, the Shell component will include the core dojo 
> > javascript object dojo.js, as well as the new core Tapestry 
> > javascript object - core.js. This means that you don't have to worry 
> > about how to include dojo or Tapestry javascript on any of your 
> > pages, they will already be available."
> >
> > Of course, that's not the case for portlets.
> >
> > Is there a simple step-by-step how-to for those of us who don't 
> > (can't) use the Shell component.
> >
> > Thanks,
> >
> > Ezra Epstein
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Jesse Kuhnert
> Tacos/Tapestry, team member/developer
>
> Open source based consulting work centered around 
> dojo/tapestry/tacos/hivemind.
>



--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around dojo/tapestry/tacos/hivemind.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to