4 Replies Latest reply on Nov 20, 2006 2:45 PM by Jerome Lazzarini

    Workspace/conversation switcher

    Jerome Lazzarini Newbie

      Hello,

      I am building a web application based on Seam 1.1 (latest build from CVS) and Icefaces 1.5.

      Basically, the application consists of a main master/detail view panel in a tabbed pane and I would like to be able to create/edit entities in tabs (of the same tabbed pane), each tab having its own conversation.

      Ideally, I should be able to use the workspace/conversation switcher. The problem is that with Icefaces, the DOM tree is built statically (no dynamic includes in tabs), which means I have many subviews included in one "main" view (template stack for those who know Icefaces). Hence, my JSF action listeners always have to return null outcomes.

      I have used session-scoped components to prototype my application and I have implemented some sort of component switching on tab change events.

      Would it be possible to bind a tab to a conversation and do automatic workspace/conversation switching ?

      The Booking application allows me to start new conversations in my browser tabs, would it be possible to do the same in JSF tabbed panels ?

      Regards,
      Jerome.

        • 1. Re: Workspace/conversation switcher
          Gavin King Master

           

          The Booking application allows me to start new conversations in my browser tabs, would it be possible to do the same in JSF tabbed panels ?


          Yes, this should definitely be possible, but I'd need to see much more of your code, and understand what you are doing a lot better to be able to tell you exactly how is the right way to approach it.

          • 2. Re: Workspace/conversation switcher
            Jerome Lazzarini Newbie

            Hello Gavin,

            I am sorry, but I cannot really post my code here (and I understand you've got a lot of work with the forthcoming 1.1GA release ;) )

            Basically, the built-in workspace switcher uses page view-ids to switch conversations, am I right ?

            The problem here is that my JSF action listeners must always return null outcomes, and I only have one main page with a lot of includes: I am using Icefaces panel stack, the DOM tree is built statically once at the beginning and then only parts of this DOM tree are updated as needed.

            I think the perfect example of the kind of behaviour I am trying to achieve is the Yahoo! Webmail (all-in-one page, tabs).

            Regards,
            Jerome.

            • 3. Re: Workspace/conversation switcher
              raffaele camanzo Newbie

              Hi Jerome,

              let me spend some words on your app, it looks really similar to the one we are implementing, the problem is that also the solution seems similar to my first approach.
              As I said in the post reply to my "problems with application like behaviour", I don't know how Icefaces work, then if this is not your scenario... simply ignore this reply.

              In my first solution I used the Tomahawk TabbedPane to handle my workspace application, every "sub-page" of the app lived in a tab inserted in the tabbedPane programmatically attaching a inner blind facelet composition inside the tab. In such behaviour, exactly as the one you described, I had to keep alive all the application in the same page (because the tab creation was created programmatically and handled intercepting actionlisteners and tabchangelisteners) and then I was not able to use meaningful outcomes (using meaningless or null returns) in my actions and (the worst) I had to handle by hand stuff like the Seam Context, the Seam Conversation and so on.
              This is evil for at least four reasons (and in my post i "tagged" it as DoNotDoThis):

              1 - No outcomes, a) no stuff in faces-config to define page switch in a "natural" way in JSF b) no page-actions c) and in my scenario no way to connect a conversation to a tab (did you do that? How?), they were stateful beans;
              2 - Minimum usage (and misuse) of Seam used as a facility to hold session data;
              3 - (this probably is Tomahawk dependant) Strange behaviour like: the tags defined in a tab were correctly rendered the first time, but, selecting another tab and re-selecting the first one, the Tomahawk tags rendering were removed from the HTML and I had more than a problem also on Seam stuff (filling fields with injection and so on);
              4 - The last and the worst: this approach is logically wrong. The usage of a rendering facility to handle such problems means move the behavioural logics of the application in a rendering tool instead of in the right place... In Seam, which has such purpose.


              Now, some words on my problem to solve:
              I have a menu and a tabbed view of my application, the selection of a menu item causes the first time the creation of a tab and after "refers to that tab" giving it the caption (it's also possible to add links in the tabs which work exactly as the menu items).

              Ok, at this point arrives the solution of the previous post I sent to you in my topic (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=93666) or you can wear the breadcrubs conversation list to make it seem like a tabbed pane (but this shows all the conversations, then if you have other conversations not involved in the tabbed pane... you see them and you have to find a way to handle this).

              The question is: if you have the solution why you are waiting for a Gavin reply?

              I have at least one problem/nightmare which breaks this solution:

              I have to recycle some of my actions and some not: I have, for example, the manageThis action that can be called on some stuffIds and must create (the first time, and then refer to) a new tab for each stuffId, but I also have a manageThat action that is always rendered in the same tab regardless of the stuffId passed.
              In this situation I have to "pre-process" the request, identify or prepare for the creation the conversation (generating the correct id) and then redirect (without making another request turnaround; for this is great the page-actions) the flow on the correct action with the correct conversation id (created/retrieved on an algorithm logics, not on the behaviour of the page)... Everything works great but... The conversation list is an unmodifiable list in the request handling (I hope "at the moment" you can set the identifier of the conversation only on the request buondaries) and this causes the raise of an exception when I try to set the conversation identifier when the page-action drives the flow to the tab page; in the action handler I generate/retrieve the conversationId and, through the page-action, I switch to the @Begin method of the conversation with the right conversationId.

              I don't know if you have the same behaviour I listed above (and then if you have to wait for a Gavin reply or study another solution), but, in any case, if this is you scenario, I think that you are moving in a dangerous way (binding the behaviour on Icefaces) because is logically wrong, because if you write everything on your own you cannot ask for help, because you have to maintain your logics over the rendering improvements/modification of the tabbedpane rendering stuff and because it's error-prone.

              I hope this post will help you!
              Regards,
              Raffaele



              • 4. Re: Workspace/conversation switcher
                Jerome Lazzarini Newbie

                Hi Raffaele,

                The main issue I'm facing seems to be related to Icefaces and conversationId propagation. Today I discovered there was a D2DSeamFaceletViewHandler, not included in the public release (11/14) but available in a special build (cf. the Seam/Icefaces booking application in icefaces.org forum). This build has better support for Seam conversations.

                I still have to test, but I think that should solve most of my problems.

                Thanks again.

                Regards,
                Jerome.