On 10/7/2011 1:48 PM, Eric Dalquist wrote:
How about we do something like: <xsl:copy-of
select"//channel[parameter[@name = 'notificationPortlet' and
@value='true']]"/> (note that XPath is off the top of my head and may
not be 100% syntactically correct but thats the idea)
Sounds good. We could even do just...
<xsl:copy-of select"//channel[parameter[@role = 'notifications']"/>
And use (only) an arbitrary publishing parameter.
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.
Yep.
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.
If it comes to it. Sounds good.
What about Jasig Widget Portlets for a home? To me, these portlets seem
like tiny things that are best included within some broader collection
or platform -- not the sort of thing you'd spin up an entire project for.
drew
-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
--
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
