On Wed, Dec 7, 2016 at 2:40 PM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote:
> > What I am missing (and what my original question was referring to) is a > > per-tab context to put things. Think eg. of a page with a data table and > > some filters. The user applies filters, clicks on one of the found items > > (navigating to a different page), edits, saves (sends the user back to > the > > page with the table) and expects the filter criteria to still be intact. > In > > a single-tab scenario the filter criteria can be stored in the session - > no > > problem. > > > > Now think of a user who uses multiple tabs with different filter criteria > > in each. This is where some sort of per-tab context/store would come in > > handy. > > > > Kind regards, > > Edmund > > > > PS: I don't see this problem in single-page application though. The page > > state itself can represent the state of the tab. > > > Only if user designs it stateless. Otherwise all state is in session by > default. To make it transparent for coder, wicket should handle it. > > > Both your problems are easily solveable by using the page instance as > > "context". > > The TabbedPanel is an instance of a Java object that is somewhere inside > of > > an instance of a Page. > > Wicket provides org.apache.wicket.ajax.AjaxNewWindowNotifyingBehavior > that > > can be used to notify the page that it is opened in a second browser > > tab/window. > > In its #onNewWindow() you can do something like: > > setResponsePage(getPage().getPageClass(), getPage().getPageParameters()) > . > > This will render a *new* instance of this page with its own TabbedPanel > > where you will have different state. > > > This does not (transparently) solve the issue with normal session > variables, such as filter etc. models in session. They are still saved if > session is the same. > It is not supposed to "solve" it. A HTTP session is something different. The HTTP session is per browser when you use cookie (JSESSIONID). If you use url-encoded jsessionid then you can have a http session per request if you want (not very useful though). I think you should ask in Sevlet container forums for this feature. It is one level before Wicket layer. > > ** > Martin > > > > > > On 12/07/2016 01:45 PM, Martin Grigorov wrote: > > > >> Could you please expand on > >> "and you do not want to make custom logic to allow multi > >> window/tab (in browser)" ? > >> > >> How exactly Wicket prevents the "multi browser tabs/windows" ? > >> > >> Martin Grigorov > >> Wicket Training and Consulting > >> https://twitter.com/mtgrigorov > >> > >> On Wed, Dec 7, 2016 at 1:37 PM, Martin Makundi < > >> martin.maku...@koodaripalvelut.com> wrote: > >> > >> If one makes a single-page application that has multiple tabs (within > one > >>> browser window), and you do not want to make custom logic to allow > multi > >>> window/tab (in browser) management into session, it would work best if > >>> there was separate "session" for each browser tab/window inside wicket. > >>> > >>> Simplest example is that session has variable "currentlySelectedTab" if > >>> you > >>> have two browser windows open both will be racing for this same > variable > >>> unless sessions are separated. > >>> > >>> So from developer's perspective, would be simplest if wicket > >>> transparently > >>> separates sessions for each browser window/tab. > >>> > >>> ** > >>> Martin > >>> > >>> > >>> > >>> 2016-12-07 14:19 GMT+02:00 Martin Grigorov <mgrigo...@apache.org>: > >>> > >>> Hi, > >>>> > >>>> What kind of problem exactly you try to solve there ? > >>>> What kind of issues do you face ? > >>>> > >>>> Martin Grigorov > >>>> Wicket Training and Consulting > >>>> https://twitter.com/mtgrigorov > >>>> > >>>> On Wed, Dec 7, 2016 at 12:07 PM, Martin Makundi < > >>>> martin.maku...@koodaripalvelut.com> wrote: > >>>> > >>>> This should be built into wicket core, automatic session management. > >>>>> > >>>> Login > >>>> > >>>>> once and enable multiple tabs and a new sub-session for each tab. > >>>>> > >>>>> If user logs out from any of the sessions, all would be invalidated. > >>>>> > >>>>> Not sure if this exists yet, but would be needed. > >>>>> > >>>>> ** > >>>>> Martin > >>>>> > >>>>> 2016-12-07 12:59 GMT+02:00 Urbani, Edmund < > edmund.urb...@lilandit.com > >>>>> > >>>> : > >>>> > >>>>> Ok, but how do you create a session per tab? Also, I would at least > >>>>>> > >>>>> need > >>>> > >>>>> to login the authenticated user in the new session. > >>>>>> > >>>>>> > >>>>>> On 12/07/2016 11:43 AM, Martin Makundi wrote: > >>>>>> > >>>>>> We have noticed that most robust if you can get different session > for > >>>>>> > >>>>> each > >>>>> > >>>>>> tab because the session shares models and will easily conflict if > >>>>>> > >>>>> session > >>>> > >>>>> is not distinct for each tab. > >>>>>> > >>>>>> > >>>>>> > >>>>>> 2016-12-07 12:42 GMT+02:00 Urbani, Edmund < > >>>>>> > >>>>> edmund.urb...@lilandit.com> > >>> > >>>> < > >>>> > >>>>> edmund.urb...@lilandit.com>: > >>>>> > >>>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> I have a some questions about the current state of this feature. > >>>>>> > >>>>>> Firstly, how reliable is it? (Works on all/current browsers? Can > >>>>>> > >>>>> still > >>> > >>>> break under certain circumstances?) > >>>>>> > >>>>>> And secondly, how would I store my own state information per > >>>>>> > >>>>> tab/window? > >>>> > >>>>> The session context seems too broad because it is shared by all tabs > >>>>>> > >>>>> and > >>>> > >>>>> the page context is too limited. > >>>>>> > >>>>>> I could make it work with the session anyway, if I can somehow > >>>>>> > >>>>> identify > >>> > >>>> the current browser tab and put things into a map accordingly. Or I > >>>>>> > >>>>> could > >>>> > >>>>> pass on all required info from page to page which would be quite > >>>>>> > >>>>> cumbersome > >>>>> > >>>>>> and conflict with my approach to use bookmarkable URLs wherever > >>>>>> > >>>>> possible. > >>>> > >>>>> Kind regards, > >>>>>> Edmund > >>>>>> > >>>>>> > >>>>>> ------------------------------------------------------------ > >>>>>> > >>>>> --------- > >>> > >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >>>>>> For additional commands, e-mail: users-h...@wicket.apache.org > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> Edmund Urbani > >>>>>> Liland IT Team > >>>>>> > >>>>>> Email: edmund.urb...@lilandit.com <edmund.urb...@lilandit.com> > >>>>>> > >>>>>> Liland IT GmbH ...does IT better > >>>>>> Tel: +43 463 220111 > >>>>>> Fax: +43 463 220111-33 > >>>>>> Tel(GER): +49 221 65028588 > >>>>>> > >>>>>> Find us at Facebook http://facebook.com/Lilandit > >>>>>> http://iventcloud.com > >>>>>> http://Lilandit.com > >>>>>> > >>>>>> <http://www.LilandIT.com> <http://www.LilandIT.com> > >>>>>> > >>>>>> Copyright © 2016, Liland IT GmbH > >>>>>> > >>>>>> Diese Mail enthaelt vertrauliche und/oder rechtlich geschuetzte > >>>>>> Informationen. > >>>>>> Wenn Sie nicht der richtige Adressat sind oder diese Email > >>>>>> > >>>>> irrtuemlich > >>> > >>>> erhalten haben, informieren Sie bitte sofort den Absender und > >>>>>> > >>>>> vernichten > >>>> > >>>>> Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte > >>>>>> > >>>>> Weitergabe > >>> > >>>> dieser Mail ist nicht gestattet. > >>>>>> > >>>>>> This email may contain confidential and/or privileged information. > >>>>>> If you are not the intended recipient (or have received this email > in > >>>>>> error) please notify the sender immediately and destroy this email. > >>>>>> > >>>>> Any > >>> > >>>> unauthorised copying, disclosure or distribution of the material in > >>>>>> > >>>>> this > >>>> > >>>>> email is strictly forbidden. > >>>>>> > >>>>>> > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > >
