with frames you still could have a problem ( i guess)

johan


On 6/30/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 = "">            if (target instanceof IBookmarkablePageRequestTarget)
            {
                IBookmarkablePageRequestTarget current = (IBookmarkablePageRequestTarget)target;
                BookmarkablePageRequestTarget redirect = new BookmarkablePageRequestTarget(
                        getSession().createAutoPageMapName(), current.getPageClass(), current
                                .getPageParameters());
                url = "">            }
            else
            {
                url = "">            }

            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

Reply via email to