[
https://issues.apache.org/jira/browse/WICKET-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12720361#action_12720361
]
Johan Compagner commented on WICKET-2204:
-----------------------------------------
no you shouldnt have to call it.
But a page that is bookmarkable can be stateless
But if you build your components and those components cant be stateless you
should tell that, like we do on all the statefull components..
thats why we have stateless link and stateless form.
By default getStatelesshint() returns true
If component has behaviors that are not stateless it will be auto statefull
But if you make a component that calls urlFor some interface you made then that
component should return false on getStatelessHint()
> 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.
