> TabbedPanel? I was talking purely about browser tabs, so let's avoid > confusion and keep TabbedPanel out of this thread. ;) >
Sorry, that's our own use case we are having trouble with =) > What you are suggesting with AjaxNewWindowModifyingBehavior is more or > less what I had in mind for a single-page application. However in a > multi-page multi-tab scenario keeping the per-tab state in the page > instance is not enough. I'd still have to pass the state between pages > instances. > > Or rather I could pass some identifier by eg. modifying my custom link > class to automatically rewrite a page parameter like (/tab/<TAB_ID>). Then > I'd store a Map<TabId, TabState> in my session to access the per-tab state > as needed. > > Kind regards, > Edmund > > > On 12/07/2016 02:27 PM, Martin Grigorov wrote: > >> 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. >> >> Martin Grigorov >> Wicket Training and Consulting >> https://twitter.com/mtgrigorov >> >> On Wed, Dec 7, 2016 at 2:13 PM, Urbani, Edmund < >> [email protected]> >> 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. >>> >>> >>> 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 < >>>> [email protected]> 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 <[email protected]>: >>>>> >>>>> 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 < >>>>>> [email protected]> 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 < >>>>>>> [email protected] >>>>>>> >>>>>>> : >>>>>> >>>>>> 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 < >>>>>>>> >>>>>>>> [email protected]> >>>>>>> >>>>>> < >>>>>> >>>>>> [email protected]>: >>>>>>> >>>>>>> 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: [email protected] >>>>>> >>>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Edmund Urbani >>>>>>>> Liland IT Team >>>>>>>> >>>>>>>> Email: [email protected] <[email protected]> >>>>>>>> >>>>>>>> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
