[
https://issues.apache.org/jira/browse/WICKET-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12720354#action_12720354
]
Johan Compagner commented on WICKET-2204:
-----------------------------------------
if we dont want those hybrid urls at all, but only for full stateless urls then
the fix is easy
instead of doing:
if (listener != IRedirectListener.INTERFACE &&
component.isStateless() &&
page.isBookmarkable() && page.getStatelessHint())
do:
if (listener != IRedirectListener.INTERFACE &&
page.isPageStateless())
question that i ask my self.. why didnt we do that in the first place?
And do we break something if we just change his?
Because now we generate urls to components that say i am stateless on a page
that is bookmarkable (and statelesshint says true so it can be stateless)
So those stateless components can be called on when the page is bookmarkable
That sound perfectly fine to me
So if people dont want that because there component is not stateless they
should return that in that componnent (getStatelessHint())
So i think the current behavior is just want we want...
> urlFor(IResourceListener.INTERFACE) returns different URLs
> ----------------------------------------------------------
>
> Key: WICKET-2204
> URL: https://issues.apache.org/jira/browse/WICKET-2204
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-RC2
> Environment: Ubuntu 8.10 / Java 1.6.0_0-b12
> Reporter: Francisco Treacy
> Assignee: Juergen Donnerstag
> Fix For: 1.5-M1
>
> Attachments: quickstart.zip
>
>
> When I call urlFor(IResourceListener.INTERFACE) in the renderHead method of
> my public abstract class SWFComponent extends WebMarkupContainer implements
> IResourceListener, IHeaderContributor
> it randomly returns two different type of URLs:
> 1. ?wicket:interface=:3:docsPanel:viewer:flash::IResourceListener:: ( this
> is the good URL I was expecting, that calls the onResourceRequested callback
> method)
> 2.
> ?wicket:bookmarkablePage=:app.wicket.document.DocumentDetailPage&wicket:interface=:10:detailPanel:viewer:flash::IResourceListener::
> (this bookmarkable link tries to point to the page that holds the instance
> of the SWFComponent - and fails because this page needs PageParameters- but
> is incorrect anyway)
> The 'randomness' seems be triggered after compilation - but is very difficult
> to reproduce. For example, after experiencing this strange behaviour in a
> development environment, I committed a "working" dev version (URL of type 1)
> to the continuous integration server. The integration app was running the
> same codebase but output URLs of type 2.
> I am attaching a quickstart that returns URLs of type 2 by the time I filed
> this issue. I tried digging into the WebRequestCodingStrategy but it was
> difficult to compare as I couldn't easily reproduce both types.
> In the quickstart I also included a splitted version of the component, i.e.
> a public abstract class SWFResourceListener extends WebMarkupContainer
> implements IResourceListener + a public class SWFBehavior extends
> AbstractBehavior implements IHeaderContributor
> in an unsuccessful attempt to see if the problem was caused by the fact of
> having component + header contributor + resource listener all in the same
> class.
> I have solved my case by swapping the IResourceListener for a plain old
> BookmarkablePage that outputs the SWF bytes, but I still think it's worth to
> have a look at this bizarre behaviour (which, by the way, might be related to
> WICKET-289 ?).
> Thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
