13 Replies Latest reply on Nov 19, 2008 9:17 AM by Jay Balunas

    a4j:queue - some comments on the wiki

    Jay Balunas Master

      Below are some comments of mine regarding the a4j:queue wiki page.

      NOTE: The view scoped queue(quque which could be used by the components in any forms) should be defined as a immediate view root child. Searching for a queues defined just anywhere also implemented but most preferable and safe way is to have it defined like mentioned above.

      Also it is preferable to defined queues before the components which uses this queues.


      We need a definitive answer to this - either users MUST put the queue immediately after the view/form root, or they can put it other places. If there are technical difficulties with having the queue's defined anywhere in the view lets discuss it, and write it up that way. We want to avoid statements like "it's implemented, but no safe" it will add confusion and instability.

      But action components could redefine some of the params on the component level and it will be used instead of queue value.


      I think that you should add the example that you sent in the email - it will help explain why this may be needed.

      OPEN ISSUE: Should this raise a warning?
      action components trying to find queues referenced by name and creates it if needed on client side. So seems the warning now could not be fired.


      I'm not sure what you are saying here? If a component is referencing a queue that has not been defined it would be detected during rendering and created server side as if it were defined - correct? I don't think that adhoc queue's should be created client side. So if the queue is created server side couldn't we raise a warning message in the server log?

      Also in order to provide default scope for implicit queues we'll introduce next context param:


      Could you explain this a little more for me? Why do we need to define scope for a global queue?

      Thanks,
      Jay



        • 1. Re: a4j:queue - some comments on the wiki
          Nick Belaevski Master

           

          "jbalunas@redhat.com" wrote:
          Below are some comments of mine regarding the <a href="http://www.jboss.org/community/docs/DOC-12894">a4j:queue wiki page</a>.

          NOTE: The view scoped queue(quque which could be used by the components in any forms) should be defined as a immediate view root child. Searching for a queues defined just anywhere also implemented but most preferable and safe way is to have it defined like mentioned above.

          Also it is preferable to defined queues before the components which uses this queues.


          We need a definitive answer to this - either users MUST put the queue immediately after the view/form root, or they can put it other places. If there are technical difficulties with having the queue's defined anywhere in the view lets discuss it, and write it up that way. We want to avoid statements like "it's implemented, but no safe" it will add confusion and instability.



          In my opinion, limitations for queue placement won't seem reasonable for users. Introducing these limitations we return back to times of JSF 1.1 where component order was much more significant than in JSF 1.2.
          It is easy to support arbitrary disposition of queue and related components in the view if we use client-side method of queues discovery and creation. In fact we have already created working prototype that uses client-side approach and is indifferent to the queues placement.

          "jbalunas@redhat.com" wrote:


          OPEN ISSUE: Should this raise a warning?
          action components trying to find queues referenced by name and creates it if needed on client side. So seems the warning now could not be fired.


          I'm not sure what you are saying here? If a component is referencing a queue that has not been defined it would be detected during rendering and created server side as if it were defined - correct? I don't think that adhoc queue's should be created client side. So if the queue is created server side couldn't we raise a warning message in the server log?



          Queues do not interact with server in any way. So they can be created client side without any problem. Can you please tell more why you don't like creation of queues on the client side?

          "jbalunas@redhat.com" wrote:

          Also in order to provide default scope for implicit queues we'll introduce next context param:


          Could you explain this a little more for me? Why do we need to define scope for a global queue?

          Thanks,
          Jay



          That is about the following case:
          <f:view>
           <h:form id="formA">
           <a4j:commandLink value="Link A"/>
           </h:form>
           <h:form id="formB">
           <a4j:commandLink value="Link B"/>
           </h:form>
          </f:view>
          


          If we turn implicit global queue on we might be thinking about single global queue for the whole view or two separate queues global to formA and formB. This feature lets us declare exactly what we need.

          Another case when that can be necessary:
          <f:view>
           <h:form id="formA">
           <a4j:commandLink eventsQueue="queue" value="Link A"/>
           </h:form>
           <h:form id="formB">
           <a4j:commandLink eventsQueue="queue" value="Link B"/>
           </h:form>
          </f:view>
          


          I've added "eventsQueue" attribute here, but the question is much the same. To what scope does "queue" queue belong?

          P.S. I think we can create two different context parameters for these two cases.

          • 2. Re: a4j:queue - some comments on the wiki
            Jay Balunas Master

             

            "nbelaevski" wrote:

            In my opinion, limitations for queue placement won't seem reasonable for users. Introducing these limitations we return back to times of JSF 1.1 where component order was much more significant than in JSF 1.2.
            It is easy to support arbitrary disposition of queue and related components in the view if we use client-side method of queues discovery and creation. In fact we have already created working prototype that uses client-side approach and is indifferent to the queues placement.


            I agree that limiting the placement of the queue seems overly confining. If we can accomplish this functionality with client side discovery lets go with that. I was just having a hard time with "preferable", and "safe" statements in the wiki - specifications should be definitive when possible.


            Queues do not interact with server in any way. So they can be created client side without any problem. Can you please tell more why you don't like creation of queues on the client side?


            I believe you are saying that when rendering a component that is using a queue there are no server side lookups to determine if the queue exists. It simply states what queue it wants to use and when needed that queue is looked up on the client. If that is the case I can understand this difficulty. So queues that are created client side have no matching component in the tree server side - right?

            Just so I can understand a little better. When you are rendering a queue component that a user has placed in the view the server is rendering something. Could you explain what is actually being rendered. Are you keeping any type of listing server side of what queue's are created?


            That is about the following case:
            <f:view>
             <h:form id="formA">
             <a4j:commandLink value="Link A"/>
             </h:form>
             <h:form id="formB">
             <a4j:commandLink value="Link B"/>
             </h:form>
            </f:view>
            


            If we turn implicit global queue on we might be thinking about single global queue for the whole view or two separate queues global to formA and formB. This feature lets us declare exactly what we need.

            It was my understanding that global queues would always be at the view level, and if a user wanted to have an implicit queue for a form they would need to define it like this:
            <f:view>
             <h:form id="formA">
             <a4j:queue ..../>
             <a4j:commandLink value="Link A"/>
             </h:form>
             <h:form id="formB">
             <a4j:commandLink value="Link B"/>
             </h:form>
            </f:view>
            

            formA will use the queue defined in it - with no name - as detailed in the wiki. Elements in formB or any other element on the page would use use the global queue unless they specifically declared a different queue using "eventsQueue".

            Another case when that can be necessary:
            <f:view>
             <h:form id="formA">
             <a4j:commandLink eventsQueue="queue" value="Link A"/>
             </h:form>
             <h:form id="formB">
             <a4j:commandLink eventsQueue="queue" value="Link B"/>
             </h:form>
            </f:view>
            


            I've added "eventsQueue" attribute here, but the question is much the same. To what scope does "queue" queue belong?



            In this case "queue" would be a new named queue that would be created client side as you discussed above. This would not be treated as an implicit queue by any view/form/element and would need to be explicitly referenced as you did in this example.



            • 3. Re: a4j:queue - some comments on the wiki
              Nick Belaevski Master

               

              "jbalunas@redhat.com" wrote:
              "nbelaevski" wrote:

              In my opinion, limitations for queue placement won't seem reasonable for users. Introducing these limitations we return back to times of JSF 1.1 where component order was much more significant than in JSF 1.2.
              It is easy to support arbitrary disposition of queue and related components in the view if we use client-side method of queues discovery and creation. In fact we have already created working prototype that uses client-side approach and is indifferent to the queues placement.


              I agree that limiting the placement of the queue seems overly confining. If we can accomplish this functionality with client side discovery lets go with that. I was just having a hard time with "preferable", and "safe" statements in the wiki - specifications should be definitive when possible.



              Sure. I'd be worried by that statements either if see in manual/user guide; they're not testable.
              We do support the feature or not. And the answer is "yes", we do.

              "jbalunas@redhat.com" wrote:

              Queues do not interact with server in any way. So they can be created client side without any problem. Can you please tell more why you don't like creation of queues on the client side?


              I believe you are saying that when rendering a component that is using a queue there are no server side lookups to determine if the queue exists. It simply states what queue it wants to use and when needed that queue is looked up on the client. If that is the case I can understand this difficulty. So queues that are created client side have no matching component in the tree server side - right?


              Exactly. Maintaining server lookup tables for each form doesn't seem like a very effective solution.

              "jbalunas@redhat.com" wrote:
              Just so I can understand a little better. When you are rendering a queue component that a user has placed in the view the server is rendering something. Could you explain what is actually being rendered. Are you keeping any type of listing server side of what queue's are created?


              • 4. Re: a4j:queue - some comments on the wiki
                Nick Belaevski Master

                 

                "jbalunas@redhat.com" wrote:
                Just so I can understand a little better. When you are rendering a queue component that a user has placed in the view the server is rendering something. Could you explain what is actually being rendered. Are you keeping any type of listing server side of what queue's are created?


                Queues data is stored in a single server registry during component tree encoding and then output into HEAD element in the same way we do for script/style resources. Here is our sandbox prototype for queues: http://anonsvn.jboss.org/repos/richfaces/trunk/sandbox/samples/queue-sample, you can check it out.



                • 5. Re: a4j:queue - some comments on the wiki
                  Nick Belaevski Master

                   

                  "jbalunas@redhat.com" wrote:


                  That is about the following case:
                  <f:view>
                   <h:form id="formA">
                   <a4j:commandLink value="Link A"/>
                   </h:form>
                   <h:form id="formB">
                   <a4j:commandLink value="Link B"/>
                   </h:form>
                  </f:view>
                  


                  If we turn implicit global queue on we might be thinking about single global queue for the whole view or two separate queues global to formA and formB. This feature lets us declare exactly what we need.


                  It was my understanding that global queues would always be at the view level, and if a user wanted to have an implicit queue for a form they would need to define it like this:
                  <f:view>
                   <h:form id="formA">
                   <a4j:queue ..../>
                   <a4j:commandLink value="Link A"/>
                   </h:form>
                   <h:form id="formB">
                   <a4j:commandLink value="Link B"/>
                   </h:form>
                  </f:view>
                  

                  formA will use the queue defined in it - with no name - as detailed in the wiki. Elements in formB or any other element on the page would use use the global queue unless they specifically declared a different queue using "eventsQueue".


                  Another case when that can be necessary:
                  <f:view>
                   <h:form id="formA">
                   <a4j:commandLink eventsQueue="queue" value="Link A"/>
                   </h:form>
                   <h:form id="formB">
                   <a4j:commandLink eventsQueue="queue" value="Link B"/>
                   </h:form>
                  </f:view>
                  


                  I've added "eventsQueue" attribute here, but the question is much the same. To what scope does "queue" queue belong?


                  In this case "queue" would be a new named queue that would be created client side as you discussed above. This would not be treated as an implicit queue by any view/form/element and would need to be explicitly referenced as you did in this example.




                  Jay, I agree with you. No need for that now, view scope is suitable for both types of queues. If someone need this parameters he'll let us know.

                  I'll ask Ilya not to put yet unreviewed features into Wiki page because it serves as a source of requirements for developers.

                  P.S. Sorry for multiple posts. Forum ate parts of my single large post and finally I gave up.

                  • 6. Re: a4j:queue - some comments on the wiki
                    Jay Balunas Master

                     


                    Exactly. Maintaining server lookup tables for each form doesn't seem like a very effective solution.


                    good I believe I understand this better, and I'll review the sandbox example for more details.

                    Jay, I agree with you. No need for that now, view scope is suitable for both types of queues. If someone need this parameters he'll let us know.


                    Yup - lets hold off and get some feedback on the first impl.

                    I'll ask Ilya not to put yet unreviewed features into Wiki page because it serves as a source of requirements for developers.


                    Thanks that is my goal - keep the wiki strictly for requirements, and open issues, and have the forums for discussions.

                    P.S. Sorry for multiple posts. Forum ate parts of my single large post and finally I gave up.


                    np - happens to us all ;-)



                    • 7. Re: a4j:queue - some comments on the wiki
                      Nick Belaevski Master

                       

                      "nbelaevski" wrote:

                      Exactly. Maintaining server lookup tables for each form doesn't seem like a very effective solution.


                      I've forgotten to say about very important motivation for moving all queue scripts into HEAD: the order of initialization on client. Queues should be initialized before components that use them. But common sequential rendering cannot guarantee that. For example of the problem: imagine long-long page with several forms and components in the first form referring to queue component that is placed as the last child in view. User can use form controls without waiting for complete page (together with queue initialization script) to load. We cannot render SCRIPT tags just before the component using the queue because we cannot guarantee that tag will be output in the correct place (e.g. for a4j:support it is impossible to render such tags because support component is fully rendered by parent component)

                      Possible solutions were:

                      1. Leave it as is and ask developer to order queues appropriately
                      2. Override form component renderer (it can have some custom functionality depending on implementation)
                      3. Create response writer that will render all queues just after form tag together with attributes is written into it
                      4. Render components sequentially and then put queues initialization before all other components.

                      We've selected point #4 as the simplest one.

                      • 8. Re: a4j:queue - some comments on the wiki
                        Ilya Shaikovsky Master

                        Wiki page updated according to your comments guys.

                        • 9. Re: a4j:queue - some comments on the wiki
                          Ilya Shaikovsky Master

                          http://www.jboss.org/community/docs/DOC-12894

                          View Changes and requests waiting in queue section

                          2.2) We plan to introduce one more common attribute which should allow to define the components which should reset the queue (resetQueueAfterRequest).


                          Guys.. lets move this feature discussion and implementation to future release?

                          • 10. Re: a4j:queue - some comments on the wiki
                            Jay Balunas Master

                             

                            "nbelaevski" wrote:

                            4. Render components sequentially and then put queues initialization before all other components.

                            We've selected point #4 as the simplest one.


                            Sounds good to me

                            • 11. Re: a4j:queue - some comments on the wiki
                              Jay Balunas Master

                               

                              "ilya_shaikovsky" wrote:

                              Guys.. lets move this feature discussion and implementation to future release?


                              Agreed - we are running low on time and we need some user feedback anyway.

                              • 12. Re: a4j:queue - some comments on the wiki
                                Vladimir Kovalyuk Apprentice

                                If I understand JSF 2.0 EDR2 spec correctly it is explicitly said that all the ajaxRequests must be put into a single client side queue. It seems for me that capability to split requests into queues won't conform the specification. I suggest enhancing the JSF spec ASAP.

                                • 13. Re: a4j:queue - some comments on the wiki
                                  Jay Balunas Master

                                  Very interesting :-)

                                  I just asked our JSF 2.0 EG members to comment on this. We should consider this closely.

                                  Thanks for pointing this out!

                                  -Jay