4 Replies Latest reply on Aug 24, 2012 2:50 AM by Andrei G

    <h:inputTextArea> inside <rich:list>

    Andrei G Newbie

      Hello,

       

      I have a <rich:list> wich is populated via <a4j:push>. Every element of the <rich:list> contains an <h:inputTextArea>. The problem is that if an user is writing something inside the <h:inputTextArea> during a list update, the text disappears. Is there a way to avoid this? I'm using RichFaces 4.2.2.Final.

       

      Thank you!

        • 1. Re: <h:inputTextArea> inside <rich:list>
          Christian Peter Expert

          check the execute attribute of your a4j:ajax / a4j:push so that the h:inputTextArea is processed on each request.

          • 2. Re: <h:inputTextArea> inside <rich:list>
            Andrei G Newbie

            Hello Christian,

             

            Thank you for your suggestion. But even if the <h:inputTextArea> is processed on each request nothing stops a user to type something between requests. I think the best solution will be to update all elements of the list except the <h:inputTextArea> where the user is typing. I know that it is not possible yet to update only some rows of a <rich:list> when new elements are added or removed from the list. I want to know if a workaround exist for this issue, specifically for my case.

            • 3. Re: <h:inputTextArea> inside <rich:list>
              Christian Peter Expert

              check if rich:list supports ajaxKeys. It's a set of integer that represent the rows which should be updated on the next render response. Here you could macgyver some logic to ignore the inputTextArea that is currently focussed. But this would probably not work properly since you have to tell the server every focus change.....

               

              let's try clientid --- javascript: check the events the a4j:push provides you. If this is not enough, try an extra a4j:status for your a4j:push. Before the DOM is updated save the value of the currently focussed inputtextarea and write the value back after the rendering is completed. I'm not sure if this handles all the cases. Maybe the users changes two or more inputs during the request. This should be possible to handle, too: track the "onfocus" event for each inputtextarea and store the ids in some javascript array which you can process later ...

               

              Or: you can simple block userinput during the requests. this can be done with a4j:status there you show an almost transparent overlay over your page.

              • 4. Re: <h:inputTextArea> inside <rich:list>
                Andrei G Newbie

                check if rich:list supports ajaxKeys. It's a set of integer that represent the rows which should be updated on the next render response. Here you could macgyver some logic to ignore the inputTextArea that is currently focussed. But this would probably not work properly since you have to tell the server every focus change.....

                     From what I know ajaxKeys are no longer supported in RichFaces 4.x. Instead there is a new way of updating datatables / list rows but that only works if the size of the backing list is not modified (not working when adding / removing an element).

                 

                let's try clientid --- javascript: check the events the a4j:push provides you. If this is not enough, try an extra a4j:status for your a4j:push. Before the DOM is updated save the value of the currently focussed inputtextarea and write the value back after the rendering is completed. I'm not sure if this handles all the cases. Maybe the users changes two or more inputs during the request. This should be possible to handle, too: track the "onfocus" event for each inputtextarea and store the ids in some javascript array which you can process later ...

                     This is the solution I've decided to try. It worked better than I expected. Whit <a4j:ajax> I've added an onbeforedomupdate event for <a4j:push> which saves the inputTextArea value and an oncomplete event which restores it.  And it seems that no user inputs are lost.

                 

                     Thank you again for all your support.