Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Component/s: Ajax/JavaScript
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      726
    • Status Whiteboard:
      Hide

      size_small importance_large

      Show
      size_small importance_large

      Description

      The 2.0 spec specifies an unlimited ajax queue, though for most usages a queue
      size of 1 is appropriate.

      This param makes the queue size configurable. Follow up requests would replace
      prior request if the queue is full.

      On jsr-314-open it was discussed whether queue size is a general config param,
      but this doesn't hit the nail:

      The desired queue size can differ with each use case, so it is meant to define
      the number of queue elements one use case tolerates before throwing one out, so
      f:ajax/jsf.ajax.request are the right place to put it.

        Activity

        Hide
        ganeshpuri added a comment -

        original discussion from jsr-314-open:

        Actually the desired queue size can differ with
        each use case, so this was meant to define the
        number of queue elements this special request
        tolerates before throwing one out, so f:ajax/
        jsf.ajax.request could be the right place to put it.

        Maybe "queue" would be nicer and more compact than "queuesize".

        Best regards,
        Ganesh

        > 3. queuesize: The 2.0 spec specifies an unlimited ajax queue, though
        > for most usages a queue size of 1 is appropriate. This param makes
        > the queue size configurable. Follow up requests would replace prior
        > request if the queue is full.
        >
        >
        > I'm not sure this is appropriate for an f:ajax tag attribute. It sets a
        application-wide flag for Ajax behaviors (correct?), and is not specific to the
        Ajax request to which the f:ajax tag is assocated.

        Show
        ganeshpuri added a comment - original discussion from jsr-314-open: Actually the desired queue size can differ with each use case, so this was meant to define the number of queue elements this special request tolerates before throwing one out, so f:ajax/ jsf.ajax.request could be the right place to put it. Maybe "queue" would be nicer and more compact than "queuesize". Best regards, Ganesh > 3. queuesize: The 2.0 spec specifies an unlimited ajax queue, though > for most usages a queue size of 1 is appropriate. This param makes > the queue size configurable. Follow up requests would replace prior > request if the queue is full. > > > I'm not sure this is appropriate for an f:ajax tag attribute. It sets a application-wide flag for Ajax behaviors (correct?), and is not specific to the Ajax request to which the f:ajax tag is assocated.
        Hide
        Ed Burns added a comment -

        triage

        Show
        Ed Burns added a comment - triage
        Hide
        Ed Burns added a comment -

        rogerk

        Show
        Ed Burns added a comment - rogerk
        Hide
        rogerk added a comment -

        target

        Show
        rogerk added a comment - target
        Hide
        ganeshpuri added a comment -

        clarification to get this into JSF 2.1:
        To reduce complexity we have only 1 AJAX request queue in JSF 2.0 as opposed to
        the concept of different queues for group of components.
        This queue param is only meant to limit the size of this one queue and to throw
        out the oldest queued request when a new one comes in.

        Show
        ganeshpuri added a comment - clarification to get this into JSF 2.1: To reduce complexity we have only 1 AJAX request queue in JSF 2.0 as opposed to the concept of different queues for group of components. This queue param is only meant to limit the size of this one queue and to throw out the oldest queued request when a new one comes in.
        Hide
        rogerk added a comment -

        triage

        Show
        rogerk added a comment - triage
        Hide
        rogerk added a comment -

        unfortunately this will have to go into 2.2

        Show
        rogerk added a comment - unfortunately this will have to go into 2.2
        Hide
        rogerk added a comment -

        triage

        Show
        rogerk added a comment - triage
        Hide
        Ed Burns added a comment -

        Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

        Show
        Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

          People

          • Assignee:
            Unassigned
            Reporter:
            ganeshpuri
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: