[
https://issues.apache.org/jira/browse/SHINDIG-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193220#comment-13193220
]
Ryan Baxter commented on SHINDIG-1549:
--------------------------------------
I figured out what is going on. The default view is aliased to home, profile,
and canvas, so if that gadget has one of those other views everything works
fine. I seem to remember this changing going in a while ago so this is
probably why the gadget started working. However if your gadget doesn't have a
home, profile, or canvas view then it will still fail.
The crux of the problem appears to be in the way the metadata request is
handled on the server when the iFrame URL is requested by the container. When
the server constructs the response to a metadata request it will try and build
the iFrame URL and part of the iFrame URL is the view to render. The metadata
request handler creates a GadgetContext object, it looks to see if a view was
specified in the metadata request and if its not it will set the view for the
GadgetContext object to default. When we process the GadgetContext object in
GadgetHandlerService.getMetadata to create a Gadget object we try to get the
view from the GadgetSpec. In the case of a metadata request for a gadget with
no default view the Gadget object will have a null view, which in turn causes
any metadata request, which needs the iFrame URL, to fail.
The metadata request, correctly, does not send any view along with it to the
server when making a metadata request. This makes sense because you are
requesting the metadata for the gadget and the container does not necessarily
know what view it is going to render. However the
DefaultIFrameUriManager.getIframeUrl_ method uses the view for several things
when constructing the iFrame URL returned in the metadata request.
1.) Sets the view query parameter in the iFrame URL. This does not necessarily
need to happen on the server as the common container will set it again in
GadgetHolder.getIframeUrl_
2.) If the view for the iFrame URL has the type URL then it will add all the
Javascript libs for this view to the URL.
3.) Its used to determine whether user preferences in the iFrame URL should be
added as query parameters or as fragments. The user preferences will be added
as query parameters is the view needs to do user pref subsitution using __UP_
or if the view has the type URL. I assume the reason for adding them as
fragments for everything else is because it allows the browser to cache the
gadget. When we rewrite the gadget we only ever look at preferences in the
query parameters not in the fragments, which makes sense since we would only
ever be doing substitution in that case.
The fact that the metadata response is cached in the common container and we
just replace key query parameters in the common container when we switch views
in that gadget reveals another bug. If the default view of the gadget you are
rendering is of type URL, than the metadata response you get back will have an
IFR URL for the URL view. In other words it will pretty much be the href
property of the view. If you switch to another view in that gadget we will get
the cached metadata and replace the view parameter in the IFR URL, but the IFR
URL is the href property from the default URL view and the content in the
gadget is incorrect!
My proposed solution to the problem is to actually return the IFR URLs for all
the different views in the gadget in the metadata request. While this will
increase the response size, it is the only way to guarantee we will be using
the correct IFR URL for the correct view we are trying to render.
> gadgets.metadata request fails for gadgets that don't have a "default" view
> ---------------------------------------------------------------------------
>
> Key: SHINDIG-1549
> URL: https://issues.apache.org/jira/browse/SHINDIG-1549
> Project: Shindig
> Issue Type: Bug
> Components: Java
> Affects Versions: 3.0.0
> Environment: Mac OSX
> Reporter: Doug Davies
> Fix For: 3.0.0
>
>
> The request for gadgets.metadata fails for a gadget spec that doesn't specify
> a "default" view. For example
> http://www.google.com/ig/modules/wikipedia.xml. The reason is in
> GadgetsHandlerService.java.
> if (needIfrUrl && gadget.getCurrentView() == null) {
> throw new ProcessingException("View " + request.getView() + " does not
> exist",
> HttpResponse.SC_BAD_REQUEST);
> }
> The gadget.getCurrentView returns null if no "default" view is defined.
> You can see this behavior by testing in the commoncontainer sample and trying
> to load the wikipedia gadget.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
