Great! One final thing I'm wondering is how this will work with
frames... It probably doesnt.
Eelco
On 6/29/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> ok, here is a pagemapchecker based on the window.name instead of cookies -
> idea burrowed from the scopes project mentioned in the tss link in eelcos
> message.
>
> this should be way more bullet proof then our cookie thing. i dont have time
> to finish it completely, johan do you think you can throw in whatever i
> didnt from your pagemapchecker into this one?
>
> once it is integrated would everyone who had problems with our auto multi
> window support give it another try, i think it will work much better now.
>
> -Igor
>
> /**
> *
> * @author ivaynberg
> */
> private final class PageMapChecker2 extends AbstractBehavior implements
> IHeaderContributor
> {
>
> /**
> *
> */
> private static final long serialVersionUID = 1L;
>
> public void renderHead(Response response)
> {
> final WebRequestCycle cycle =
> (WebRequestCycle)getRequestCycle();
> final IRequestTarget target = cycle.getRequestTarget();
>
> int initialAccessStackSize = 0;
> if
> (getApplication().getRequestCycleSettings().getRenderStrategy()
> == IRequestCycleSettings.REDIRECT_TO_RENDER
> && target instanceof RedirectPageRequestTarget)
> {
> initialAccessStackSize = 1;
> }
>
> String name = getPageMap().getName();
> if (name == null)
> {
> name = "wicket:default";
> }
>
> // TODO escape " in the name
>
> CharSequence url = null;
> if (target instanceof IBookmarkablePageRequestTarget)
> {
> IBookmarkablePageRequestTarget current =
> (IBookmarkablePageRequestTarget)target;
> BookmarkablePageRequestTarget redirect = new
> BookmarkablePageRequestTarget(
>
> getSession().createAutoPageMapName(),
> current.getPageClass(), current
> .getPageParameters());
> url = cycle.urlFor(redirect);
> }
> else
> {
> url =
> urlFor(INewBrowserWindowListener.INTERFACE);
> }
>
> final ArrayListStack accessStack =
> getPageMap().getAccessStack();
> if (accessStack.size() == initialAccessStackSize)
> {
> // this is the first access to the pagemap, set window.name
> response.write ("<script>window.name=\"" + name +
> "\";</script>");
> }
> else
> {
> response.write("<script>if (window.name=='' )
> window.location=\"" + url
> + "\";</script>");
>
> }
>
> }
>
> }
>
>
>
> On 6/29/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> >
> > yep, lets do it. do we know if window.name is supported on all browsers?
> if it is then this can seriously rock.
> >
> >
> > -Igor
> >
> >
> >
> > On 6/29/06, Eelco Hillenius <[EMAIL PROTECTED]> 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
