Hi,Chris:
You mean I can't use cl:link to pass information to a CachingURICoplet?
If so,I must use bookmark to accees a CachingURICoplet or not using
CachingURICoplet,is that correct?
That's what make me confused.
Thanks for replying.
Roy Huang
----- Original Message -----
From: "Christian Mayrhuber" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 02, 2004 6:01 PM
Subject: Re: cl:links in cachingURI coplet ?
> On Friday 02 July 2004 09:15, roy huang wrote:
> > Hi,Chris:
> > I change the uri attribute because I change GAlleryViewer from URICoplet
> > to CachingURICoplet,the CachingURICoplet need to change the original
> > attribute.What make me stuffed is CachingURICoplet not URICoplet.Maybe it
> > is a CachingURICoplet's bug.
> >
> > Roy Huang
>
> The CachingURICoplet has some features that don't make any sense to be used
> with the Gallery coplet, because the gallery viewer does not know anything
> about the application-uri temporary attribute.
> You would need an extra coplet like the one accessing woody forms if you want
> to use the application-uri with the Gallery coplet, it will not though.
> The Gallery coplet works vastly different. It generates its own portal events
> to do inter-coplet communication.
> If you look at gallery.xsl you will notice the line:
>
> <cl:link path="attributes/picture" value="{picture[position()=$showpicindex]}"
> coplet="GalleryViewer-1">Push to Viewer</cl:link>
>
> The above line generates a CopletEvent setting the CopletInstanceData
> attribute "picture" of the GalleryViewer-1 coplet instance to the selected
> image.
> The result is that the GalleryViewer-1 displays the image.
>
> If you change
> <attribute>
> <name>uri</name>
> <value xsi:type="java:java.lang.String"
>
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>cocoon:/coplets/html/application</value>
>
> </attribute>
> the coplet cannot be accessed anymore because it does not refer to the
> GalleryCoplet. Changing the uri attribute back to the Gallery coplet will
> make it work again, but the advanced capabilities of the CachingURICoplet
> will not be used.
>
> The idea of the CachingURICoplet is a different one. Let's assume you have
> an cocoon application outside of the portal that you want to include, but you
> don't want to rewrite it to generate coplet events by means of
> <cl:link ..../> and the CopletTransformer. In this case the CachingURICoplet +
> HTMLEventLinkTransformer enables you to write a simple coplet to include your
> application as coplet.
>
> If you have a look at http://localhost:8888/docs/developing/portal/forms.html
> you can see that the temporaryAttributes/application-uri attribute is accessed
> in the sitemap and used to generate the xml.
> Next, this xml is transformed by the HTMLEventLinkTransformer to generate
> <cl:link ...> elements.
> Finally, the CopletTransformer transforms the <cl:link ...> into portal events
> which set the temporaryAttributes/application-uri once a form or hyperlink is
> clicked.
>
> --
> lg, Chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
