Thanks for the explanation. I guess it's another technology I'll have to
add to my list of 'to do's.
Re your issue - I see why you want to pass an 'attributes' generic
object now. I thought it was way too non-specific and would lead you
into a bit of a mess, but I guess if you are mimicing portlet behaviour,
then it's what you need.
Adam
[EMAIL PROTECTED] on 27/07/05 13:26, wrote:
Portlets are java mini applications that work within the Java Portlet
Specification. They are ment to run using a Portal Server like Websphere
Portal server, Metadot, or jetspeed. These 'applications' can share
variables, etc via the Portlet container. The container manages the
placement and look and feel of the applications in a simular fashen to
the tiles layout, but come with a overhead cost. (I would venture to say
much larger than the tiles overhead).
Re: [Tiles] Sharing Context Between Two Tiles
Basically that is the way you do it, although I'm not really sure from
your description that I know why you thought you could achieve what it
looks like you were attempting.
A question for you that bugs me everytime I see 'portlet' come up: what
on earth are portlets? Are they meant to be a different technology to
'servlets'? Surely not, as you are using JSPs.
Adam
Ian Brandt on 26/07/05 18:17, wrote:
> Hello All,
>
> I'm trying to write a portlet like component using tiles. A simplified
> version of my first attempt follows:
>
> The portlet definition:
>
> <definition name=".uicomponents.portlet"
> path="/tiles/uicomponents/portlet.jsp">
>
> <put name="content"/>
> </definition>
>
>
> portlet.jsp:
>
> [...]
>
> <div class="portletStyle">
> <tiles:insert attribute="content"/>
> </div>
>
>
> The definition for a particular portlet:
>
> <definition name=".portlets.oneportlet"
> extends=".uicomponents.portlet ">
>
> <!-- For this definition we're going to use this JSP as
> the portlet content... -->
> <put name="content" value="/portlets/oneportlet.jsp/>
> <!-- We're also going to define a parameter that is
> required by oneportlet.jsp -->
> <put name="aParam"/>
> </definition>
>
>
> oneportlet.jsp:
>
> [...]
>
> <tiles:useAttribute id="aParam"
> name="aParam" classname="com.mycompany.SomeClass"/>
>
> <c:out value="${aParam.someProperty}"/>
>
>
> Finally a body page that inserts oneportlets:
>
> [...]
>
> <c:forEach var="someClass"
> items="${requestScope.collectionOfSomeClasses}">
>
> <tiles:insert definition=".portlets.oneportlet">
> <tiles:put name="aParam" beanName="someClass"/>
> </tiles:insert>
> </c:forEach>
>
>
> Upon trying this I found that aParam is not available to oneportlet.jsp
> (attribute not found error on tiles:useAttribute). I did find that
> aParam was available to portlet.jsp. From this I realized that my
> tiles:insert in portlet.jsp was creating a new tile context for
> oneportlet.jsp, and the fact that my .portlets.oneportlet definition was
> extending .uicomponents.portlet did not mean that their context would be
> shared.
>
> The only solution I've been able to think of so far is to add a generic
> "attributes" attribute to my base portlet definition, and just pass that
> on the insert of the content defined by the extending definition:
>
> The new portlet definition:
>
> <definition name=".uicomponents.portlet"
> path="/tiles/uicomponents/portlet.jsp">
>
> <put name="content"/>
>
> <put name="attributes"/>
> </definition>
>
>
> The new portlet.jsp:
>
> [...]
>
> <div class="portletStyle">
> <tiles:importAttribute name="attributes"/>
> <tiles:insert attribute="expandedContent">
> <tiles:put name="attributes" beanName="attributes"/>
> </tiles:insert>
> </div>
>
> My body page has to build up a collection of all the parameters that
> oneportlet needs (either from the action or using scriptlets), and
> oneportlet has to iterate through that collection pulling out the
> parameters it needs. It's hard read and maintain.
>
> So thanks for listening to this point, and now for my question: can
> anyone think of a better approach? My next attempts were going to be
> seeing if a tiles controller for .uicomponents.portlet could copy it's
> context to the inserted content, or trying a JSTL import instead of a
> tiles insert and seeing if the portlet's tiles context would be
> available to the imported page. Is there an entirely different way to
> look at this that I'm not thinking of?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
