11 Replies Latest reply on Mar 5, 2009 6:36 PM by Nick Belaevski

    New Component Planning <a4j:queue/>

    Jay Balunas Master

      The RichFaces team is going to develop a new component that will take ajax event queue's to the next level. We wanted to open the discussion to the community and get feedback and ideas for it.

      Below are current plans and open issues. The initial functional spec is http://anonsvn.jboss.org/repos/richfaces/management/design/queue/. This has not been updated from the initial document so several of the items are out of date or in open discussion as outlined below.

      Intro

      Tag name: <a4j:queue/>

      OPEN ISSUE: Should this be <rich:queue/>

      This tag will be used to create specific queues that various components can reference and use. Common options can be set to govern the queue. Queue properties can be set in one location (queue element) or overrode by specific components.

      To define and reference a new queue:

      <a4j:queue name="queue1" />
      
      <h:inputText value="#{foo2.bar1}">
       <a:support id="onblur" event="onblur" reRender="bar21" eventsQueue="queue1"/>
      </h:inputText>
      


      Global Queue
      There will be a default or global queue component that can be used by all elements and is enabled by default. This can be referenced using the fully qualified queue name "org.richfaces.queue.global". All components that do not state an eventQueue will use this queue. The global queue is limited to one per view - if more than one defined an exception will be thrown.

      If not defined specifically the global queue attributes will be set to the default values.

      <a4j:queue name="org.richfaces.queue.global" ... />
      


      OPEN ITEM: Should it be enabled or disabled by default? One option is that this is controlled via a context param.
      OPEN ITEM: Should default use of the global queue by all components be adjustable?

      QUEUE Attributes and Defaults
      Below is a listing of the various attributes that queues can have and what the default setting are.

      OPEN ISSUE: how useful is it to be able to set default values for all queues - either via context variables, or a tag in the view?

      OPEN ITEM: default values?

      -- requestDelay [?]- as document elsewhere

      -- timeout [500?] - ms for event timeout

      -- limittolist [empty] - as documented elsewhere

      -- ignoreDupResponses [true?] - as documented elsewhere

      -- size - the time that the queue is allowed to grow to ( -1 = unlimited, 0 = disabled, x = some number)

      OPEN ITEM: what is the behavior when the size limit is reached?
      - Fire the event immediately
      - Reject the event
      - throw and exception
      - in any of these cases a call back JS method should able to be defined and called if this happens.

      As stated above each of these settings can be overridden on a per component basis. For example a components specific event may require DB access and the developer knows that the queue's timeout is not enough. The developer could override the "timeout" attribute for it's specific event.

      OPEN ITEM: Is this a good idea, or should the event in question use a different queue?

      <a4j:queue name="queue1" timeout="1000"/>
      
      <a4j:commandButton eventQueue="queue1" timeout="5000" >
      
      



      Different ways to use the queues

      Queues can be referenced by individual components such as:

      <a4j:queue name="queue1" />
      
      <h:inputText value="#{foo2.bar1}">
       <a:support id="onblur" event="onblur" reRender="bar21" eventsQueue="queue1"/>
      </h:inputText>
      
      <a4j:commandButton eventQueue="queue1" .. >
      


      Or queues can be referenced by forms so that all richfaces ajax requests in the form will use that queue unless a component specifically sets a different queue:

      <h:form>
       <a4j:queue name="foo2"/>
       <a4j:commandButton > <!-- uses "foo2" -->
       <a4j:commandButton eventQueue="queue1" > <!-- uses "queue1" -->
      

      OPEN ITEM: do we limit this to only a4j:form components?

      If a queue is references by a component, but a queue with that name does not exist a new a4j:queue will be created with all default settings, and be named as per the component that is calling it.

      OPEN ITEM: How is this different than defining a new queue?

      Misc

      It will be possible to disable a queue and use it simply as a way to set event attributes that can be used by multiple components. This can be done by TBD.

      OPEN ITEM: how to disable a queue? Set size to "0", or specifically set a new attribute "enabled="false""?
      OPEN ITEM: is this useful? will it be used?

      Callbacks: Possible callbacks could be: onExpired, onError, onSizeExceeded. Developers could define corresponding handlers with these attributes.

      Some other possible callback: onSubmit, onComplete, onBeforeDomUpdate, etc...

      OPEN ITEM: Thoughts?

      Future Ideas
      programmatic Queue management could be possible using a mechanism like

      "#{rich:component('queueId')}"


      with possible methods on the object as below:

      getQueueSize()
      getEvents()
      clear()
      removeEvent(i)
      Event.getSource()

      OPEN ITEM: what other methods would be useful?


        • 1. Re: New Component Planning <a4j:queue/>
          Nick Belaevski Master

          Jay,

          thank you for putting all this together!

          One more point to discuss:

          Misc

          OPEN ITEM: Should queue component be updateable by AJAX? And how if yes?

          • 2. Re: New Component Planning <a4j:queue/>
            Nick Belaevski Master

            Links to JIRA issues for the topic:

            https://jira.jboss.org/jira/browse/RF-3131 - Implement properly requests queue for a AJAX submit.
            https://jira.jboss.org/jira/browse/RF-4387 - Event queues for groups of components
            https://jira.jboss.org/jira/browse/RF-4328 - Give default values to eventsQueue/requestDelay/ignoreDupResponses

            • 3. Re: New Component Planning <a4j:queue/>
              Pete Muir Master

               

              "jbalunas@redhat.com" wrote:
              OPEN ISSUE: Should this be <rich:queue/>


              No, we have a split between infrastructure components (a4j) and components (rich) - this is a historical artifact and we should value consistency here IMO.

              OPEN ITEM: Should it be enabled or disabled by default? One option is that this is controlled via a context param.


              Disabled, controlled by a context param

              OPEN ITEM: Should default use of the global queue by all components be adjustable?


              No, but the queue itself should be optional

              OPEN ITEM: what is the behavior when the size limit is reached?
              - Fire the event immediately
              - Reject the event
              - throw and exception
              - in any of these cases a call back JS method should able to be defined and called if this happens.


              Should be configurable

              OPEN ITEM: Is this a good idea, or should the event in question use a different queue?


              Good idea.

              OPEN ITEM: do we limit this to only a4j:form components?


              No, h:form as well

              If a queue is references by a component, but a queue with that name does not exist a new a4j:queue will be created with all default settings, and be named as per the component that is calling it.

              OPEN ITEM: How is this different than defining a new queue?


              Allows you not to have to use a:queue for a single queue.

              Misc

              It will be possible to disable a queue and use it simply as a way to set event attributes that can be used by multiple components. This can be done by TBD.

              OPEN ITEM: how to disable a queue? Set size to "0", or specifically set a new attribute "enabled="false""?
              OPEN ITEM: is this useful? will it be used?


              Why, this seems like just overloading the queue's semantics.

              • 4. Re: New Component Planning <a4j:queue/>
                Jay Balunas Master

                 

                "pete.muir@jboss.org" wrote:
                "jbalunas@redhat.com" wrote:
                OPEN ISSUE: Should this be <rich:queue/>


                No, we have a split between infrastructure components (a4j) and components (rich) - this is a historical artifact and we should value consistency here IMO.



                Excellent


                OPEN ITEM: do we limit this to only a4j:form components?


                No, h:form as well


                I agree, but we need to define an approach to associate a h:form with a specific queue. Perhaps something like the "for" attribute from JSF data scrollers. The queue could define what elements it works with. Although I would prefer to keep the relationship one way - components reference queues - not queues reference components. I would also like to avoid another tag for this.

                Maybe a queue could either a "for" or a "name" but not both - so the relationship can be both ways, but only one way at time :-)



                • 5. Re: New Component Planning <a4j:queue/>
                  Ilya Shaikovsky Master

                  Guys! I've updated the RS according to your letters and comments there.

                  Pete, one thing you mentioned there. Form referenced queue.. Do we really need it? From the beggining we've designed view referenced queue only.

                  If we should add this one also then probably the behavoiur should be:

                  1) queue placed outside the form should be used by all the controls in any forms on the page.

                  2) queue placed inside a form element should be applied to this form only and should replace the queue described in 1).

                  And in this case we should define one more "global" name.. for the queue defined without name in form and aplicable to all form elements by default.

                  Is it ok?

                  • 6. Re: New Component Planning <a4j:queue/>
                    Jay Balunas Master

                     

                    "ilya_shaikovsky" wrote:

                    1) queue placed outside the form should be used by all the controls in any forms on the page.


                    If components don't reference a queue then they use the "global" queue in this situation - if they reference a specific queue they use that.


                    2) queue placed inside a form element should be applied to this form only and should replace the queue described in 1).


                    In essence a queue defined within a form overrides the global queue as a the default queue for the components with in. It is basically a scoping mechanism for what queue is the "default" queue. Individual components can still reference any specific queue by name to override the default.


                    And in this case we should define one more "global" name.. for the queue defined without name in form and aplicable to all form elements by default.


                    I don't think this is needed, and would complicate things. As above a queue defined in a form overrides the default global queue. This queue must be named so a special name is not needed.

                    OPEN ITEM: What if more that one queue is defined with a form? Take the first?

                    • 7. Re: New Component Planning <a4j:queue/>
                      Ilya Shaikovsky Master

                      but why we should add some additional attribute like for? Could we just check for the queue if its placed inside the form or not by ourselves?

                      • 8. Re: New Component Planning <a4j:queue/>
                        Jay Balunas Master

                        With your following on comments and my reply I do not think we need to do something like the "for" attribute. Detecting it is better approach - much like a4j:support.

                        I'm sorry I did not make that clear.

                        -Jay

                        • 9. Re: New Component Planning <a4j:queue/>
                          Pete Muir Master

                           

                          "ilya_shaikovsky" wrote:
                          Guys! I've updated the RS according to your letters and comments there.

                          Pete, one thing you mentioned there. Form referenced queue.. Do we really need it? From the beggining we've designed view referenced queue only.

                          If we should add this one also then probably the behavoiur should be:

                          1) queue placed outside the form should be used by all the controls in any forms on the page.

                          2) queue placed inside a form element should be applied to this form only and should replace the queue described in 1).

                          And in this case we should define one more "global" name.. for the queue defined without name in form and aplicable to all form elements by default.

                          Is it ok?


                          I like it.

                          • 10. Re: New Component Planning <a4j:queue/>
                            Arbi Sookazian Master

                            I've responded to this thread: http://www.jboss.org/community/docs/DOC-12894

                            I haven't used a4j:queue yet (we're looking to upgrade from 3.2.1GA to 3.3.0.GA soon!)

                            My only request/requirement is to be able to use a global default queue, even if a a4j:queue tag does not exist in the xhtml page.

                            Will the a4j:queue component support this? I understand that there is a global default queue, but it seems like the RF/Seam developer must add the <a4j:queue> to every xhtml page for the queue to be active. Is this correct?

                            I am looking for this kind of functionality (i.e., no action required from the RF/Seam developer):

                            Contention for the conversation isn't seen when using ICEfaces since the ICEfaces framework automatically synchronizes requests from the same page to ensure that the server-side DOM remains uncorrupted.


                            source: Seam in Action, section 12.1.3

                            According to JBalunas:
                            To have a global queue all you need to do is set the context param.


                            Ok so if we do that, do we need to still add a <a4j:queue> component to each page that needs this queue service?

                            • 11. Re: New Component Planning <a4j:queue/>
                              Nick Belaevski Master

                               

                              "asookazian" wrote:

                              Ok so if we do that, do we need to still add a <a4j:queue> component to each page that needs this queue service?

                              No, that's not necessary.