does a frame really has another window.name even if they are in the same window?

On 6/30/06, Matej Knopp < [EMAIL PROTECTED]> wrote:
I think, we should seriously consider replacing the cookie thing with
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 will be target_window_name.

So instead of _javascript_ checking  window.name != '' i suggest
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 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
> _______________________________________________
> Wicket-develop mailing list
> Wicket-develop@lists.sourceforge.net
> 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
Wicket-develop@lists.sourceforge.net
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
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop

Reply via email to