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
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
