2 Replies Latest reply on Mar 30, 2009 10:12 PM by vk101

    begin-conversation join="true" only works when cid set?

      I've got a page in pages.xml that has a <begin-conversation join="true" /> - when I access that viewId by typing it straight into the browser (e.g. /myView.xhtml) it renders the page. When I refresh that page, I surprisingly get a new conversation every time as shown by the output of #{conversation.id} on that page - surprising because I set join="true".

      If, however, I access the page for the first time /myView.xhtml, then take the conversation id and access it the next time with /myView.xhtml?cid=#, then every subsequent refresh actually joins the previous conversation.

      If <begin-conversation join="true" /> requires cid to be set, I would assume that it would automatically redirect to /myView.xhtml?cid=1 upon the very first access - if a user accesses /myView.xhtml then refreshes the page, they're getting a new conversation every time - if that's the case, what's the purpose of <begin-conversation join="true" />? I'm confused...

        • 1. Re: begin-conversation join="true" only works when cid set?

          Define refresh that page in your first case.  If you are accessing the main URL as a GET request, then this is a new conversation. 

          If you want redirect after GET behavior on your page, you are free to do that.  Most people wouldn't want that.  In fact, starting a conversation on a GET request is generally not the way you want to go.  Most people will have the initial page be in a temporary conversation and only move into a conversation when the user takes some action from that page.  I'm not saying it never makes sense to do that, but that's what I would consider the normal best practice.

          • 2. Re: begin-conversation join="true" only works when cid set?

            To clarify, when you say redirect-after-GET, do you mean redirect to the same view but append the cid request parameter to it?

            You're right, by refreshing I do mean accessing it through a GET, either by refreshing the page by hitting the browser's refresh button or equivalent.

            I can see what you mean where most people wouldn't really need this. (The only reason I'm even considering redirect-after-GET is for efficiency purposes, whereby the queries to populate that page wouldn't be run upon each refresh.)