That way any portlet can fill the role, it just needs to be tagged with the appropriate portlet parameter in the portlet definition. We can use the same approach for the tips content.
If there is a chance of multiple portlets for one role you can add to the XPath to sort by some attribute and just grab the first one.
-Eric On 10/07/2011 03:42 PM, Drew Wills wrote:
On 10/7/2011 12:31 PM, Eric Dalquist wrote:Why do they need to be framework portlets? Do they really need access to some internal uPortal API? Could we just use a combination of the allowExpandedContent feature, portlet definition parameters, and some structure/theme XSL modifications to make this work? Unless a portlet really needs access to uPortal internals it would be nice to have it in its own webapp.That's fine -- I'd be totally ok with that.The main bit that made me think "framework portlet" was the fact that we'd want a line like...<xsl:copy-of select"//channel[@fname = 'xyz']"/>right in the theme XSL. (REMINDER for others -- if you don't have xyz portlet in your layout/portal, this XSL is a no-op. So there's little harm in including it, even if some schools won't choose to use it.)To my thinking, it made less sense to name a non-framework portlet directly in the theme.Also there's the notion that the Tips portlet is full of uP platform info (though I guess originating at publish-time, assuming PortletPrefs for data), and there's little sense in putting that specific content in a portable portlet.If not framework portlets, my next inclination would be JasigWidget. drew
smime.p7s
Description: S/MIME Cryptographic Signature
