I changed it now to this: (pretty much igors code)
<script type="text/_javascript_"><!--/*--><![CDATA[/*><!--*/That is the script done when the pagemap is in its initalized state
window.name="wicket-1";
/*-->]]>*/</script>
And this script:
<script type= "text/_javascript_"><!--/*--><![CDATA[/*><!--*/
if (window.name=='' || window.name !='wicket-0') window.location="/wicket/pub?wicket:interface=wicket-0:0::INewBrowserWindowListener";
/*-->]]>*/</script>
So when the name = '' or not the pagemap name we do a redirect.
We do keep the problem Matej is describing.. If you are in the default pagemap when you hit for the first time
And then you close the browser and come back. And the session is still there then the default pagemap will never be or
used anymore because it will always redirect to another pagemap.
I currently don't see away around that.
johan
On 6/30/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
Anyway, there is one problem with window.name that cookies solve.
Say you have an empty page map, open your browser and point to e.g.
http://localhost:8080/we/linkomatic
do some browsing there and close the tab (not entire browser, so that
session cookie is still available).
Open http://localhost:8080/we/linkomatic once again. I suppose it would
redirect to http://localhost:8080/we/linkomatic?wicket:pageMap=wicket-0
. The reason is that pagemap is no longer empty and window.name is null.
Cookies approach solve this, because onUnload deletes the pagemap cookie.
-Matej
Matej Knopp wrote:
> Yes, window.name is specific for each frame. It can be different of the
> window.name of the frameset.
>
> -Matej
>
> Johan Compagner wrote:
>> does a frame really has another window.name <http://window.name> even if
>> they are in the same window?
>>
>> On 6/30/06, *Matej Knopp* < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>>
>> I think, we should seriously consider replacing the cookie thing with
>> window.name <http://window.name> in 1.2.1. (or 1.2.2 possibly)
>>
>> In 2.0, it would be nice to have Window instead of PageMap. But I'm not
>> sure with this in case you store all you pages on disk. Then it make
>> sense to have it called PageMap.
>>
>> Frames should not be a problem. You can specify
>>
>> <FRAME src="" name="target_window_name"> so in the
>> newwindow.html window.name <http://window.name> will be
>> target_window_name.
>>
>> So instead of _javascript_ checking window.name <http://window.name>
>> != '' i suggest
>> window.name < http://window.name> != '<current_pagemap_name>'.
>>
>> Then <frame src="" name="pmHeader"> could
>> do the trick for frames.
>>
>> Same should apply for popup. You can specify the window.name
>> <http://window.name> as target
>> attribute in anchor. You can also specify it as second argument of
>> window.open.
>>
>> -Matej
>>
>> Eelco Hillenius wrote:
>> > There has been a bunch of problems with PageMaps lately and there
>> has
>> > been some talk about totally gettting rid of them (on ##wicket).
>> >
>> > Here is what I think:
>> >
>> > * PageMaps have been badly named from the start.
>> >
>> > * Our current cookie based support with _javascript_ fallback turns
>> out
>> > to be somewhat fragile. However, the way scope seems to do it (see
>> > http://www.theserverside.com/news/thread.tss?thread_id=41119), using
>> > the window name, seems pretty cheap and robust to me. Maybe we can do
>> > something like that too?
>> >
>> > * PageMaps conceptually are great. Discussions about the page map
>> > usually focus around solving back button problems, but another
>> > dimension of page maps is the scope they represent: window. We
>> > currently have application/ session/ component scopes, and that's
>> > usually enough. However, depending on what you do with the session,
>> > you might run into trouble when users utilize multiple windows. For
>> > instance, say you build an application where you store a certain
>> > operation context in the session ( e.g. a departement that a user
>> > selects after logging on). Storing that in the session will prevent
>> > the use of another operation context in another window on the same
>> > session. Currently such multi window support would be hard to
>> achieve.
>> > Wouldn't it be cool/ useful to have the concept of Windows in our
>> > Session (and then ditching PageMaps)? E.g.. Session could have
>> factory
>> > method newWindow(String name) and accessor getWindow(String
>> name), and
>> > Window would be a fairly shallow object that can be used to store
>> > stuff in the same fashion of Session. If we can fix our multi window
>> > support to be based on unique window names instead of the cookie
>> trick
>> > we're using, we can align that with names of the server side window
>> > representation. I think it would be pretty powerful.
>> >
>> > What do you think?
>> >
>> > Eelco
>> >
>> > Using Tomcat but need to do more? Need to support web services,
>> security?
>> > Get stuff done quickly with pre-integrated technology to make
>> your job easier
>> > Download IBM WebSphere Application Server v.1.0.1 based on Apache
>> Geronimo
>> >
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
>> > _______________________________________________
>> > Wicket-develop mailing list
>> > [email protected]
>> <mailto: [email protected]>
>> > https://lists.sourceforge.net/lists/listinfo/wicket-develop
>> >
>>
>>
>> Using Tomcat but need to do more? Need to support web services,
>> security?
>> Get stuff done quickly with pre-integrated technology to make your
>> job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
>> _______________________________________________
>> Wicket-develop mailing list
>> [email protected]
>> <mailto: [email protected]>
>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Wicket-develop mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
>
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Wicket-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
