You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Ganesh Jung (JIRA)" <de...@myfaces.apache.org> on 2009/04/01 13:17:12 UTC

[jira] Created: (MYFACES-2174) MyFaces 2.0 AJAX API extension proposal

MyFaces 2.0 AJAX API extension proposal
---------------------------------------

                 Key: MYFACES-2174
                 URL: https://issues.apache.org/jira/browse/MYFACES-2174
             Project: MyFaces Core
          Issue Type: Sub-task
          Components: JSR-314
    Affects Versions: 2.0.0-alpha
         Environment: browser independent javascript
            Reporter: Ganesh Jung


JSF AJAX as defined in the spec is lacking several features that are needed to make up for a good AJAX experience. They would be easy to implement, because the underlying J4Fry AJAX already supports them, so we'd only need to pass the parameters from the JSR 314 AJAX API to the implementation. Though these are extensions to the specs I recommend implementing them along with the MyFaces 2.0 AJAX core because they are hardly separable from the standard xhr request and callback. Please comment on these extensions.

Here's the proposal for MyFaces 2.0 extensions to the JSR 314 AJAX API:

current API:
j4fry.faces.Ajax.ajaxRequest(this, event, {execute: (componentIds), render: (componentIds)}

proposed API (all additional attribute are optional, so spec conformant requests are still supportet):
j4fry.faces.Ajax.ajaxRequest(this, event, {execute: (componentIds), render: (componentIds), disable: (keywords/componentIds), submit: (componentsIds), queuesize: (int), loadingbar: (image url), errorlevel: (warning/error/fatal), execbefore: (JS function), execafter: (JS function)})

And here is what the additional attributes are meant to do:

disable:
If the JSF developer wants to stop the user from givin additional input on certain or all components before the response is complete he can set this attribute. The designated components are disabled before the xhr request is made and only become reenabled when the xhr callback completes. It's impossible to implement this based on the specs API because there is no means to know at which point the callback completes.
Possible values are:
Either a keyword from this list

    * ALL (all elements)
    * BUTTON (all input-elements with type 'button')
    * SUBMIT (all input-elements with type 'submit')
    * RESET (all input-elements with type 'reset')
    * TEXT (all input-elements with type 'text')
    * RADIO (all input-elements with type 'radio')
    * CHECKBOX (all input-elements with type 'checkbox')
    * SELECT (all select-elements)
    * TEXTAREA (all textarea-elements)
    * A (all hyperlinks - a-elements)

or the component id's of the elements to disable.
Defaults to 'SUBMIT, RESET, BUTTON, A'.

submit:
If set, the PPS (partial page submit) feature becomes active. Only the elements numbered in this attribute will become submitted and only the corresponding components will be called for apply request values and update model.

queuesize:
The desired size of the request queue. For most applications it makes sense to set this to 1. Default is unlimited.

loadingbar:
During AJAX requests applications usually want to make visible some animated gif like a turning snake or similar. In this attribute the developer can pass the id of an img element. The img should be set to visibility: hidden when the page builds up and will be set to visibility: visible during the request. Again, it's impossible to implement this based on the specs API because there is no means to know at which point the callback completes.

errorlevel:
Will bring up an alert box displaying Javascript errors. This is very helpful for debugging purposes. Possible level values are: warning, error, fatal, none. default is 'none'.

execbefore:
Javascript code that will be executed before the xhr request. Setting this attribute is actually very similar to writing the script code right in front of the actual AJAX call, but there is a slight difference: Exceptions or return false in front of the AJAX call will hinder the request. Execbefore will catch exceptions and only display them when errorlevel <= warning and return false will have no effect.

execafter:
Javascript code that will be executed after the xhr callback has returned. In many cases scripts are only to be called after the callback has returned and the manipulations of the DOM tree are finished. This attribute is a hook for these scripts. Execafter will catch exceptions and only display them when errorlevel <= warning.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (MYFACES-2174) MyFaces 2.0 AJAX API extension proposal

Posted by "Ganesh Jung (JIRA)" <de...@myfaces.apache.org>.
     [ https://issues.apache.org/jira/browse/MYFACES-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ganesh Jung updated MYFACES-2174:
---------------------------------

    Resolution: Fixed
        Status: Resolved  (was: Patch Available)

> MyFaces 2.0 AJAX API extension proposal
> ---------------------------------------
>
>                 Key: MYFACES-2174
>                 URL: https://issues.apache.org/jira/browse/MYFACES-2174
>             Project: MyFaces Core
>          Issue Type: Sub-task
>          Components: JSR-314
>    Affects Versions: 2.0.0-alpha
>         Environment: browser independent javascript
>            Reporter: Ganesh Jung
>             Fix For: 2.0.0-alpha
>
>         Attachments: patch-2174.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Here's the proposal for MyFaces 2.0 extensions to the JSR 314 AJAX API:
> proposed API (all additional attribute are optional, so spec conformant requests are still supportet):
> jsf.ajax.request(this, event, {execute: (componentIds), render: (componentIds), myfaces: {pps: (true/false), queuesize: (int), errorlevel: (warning/error/fatal)})
> And here is what the additional attributes are meant to do:
> pps:
> If set to true, the PPS (partial page submit) feature becomes active. Only the elements numbered in attribute execute will become submitted.
> queuesize:
> The desired size of the request queue. For most applications it makes sense to set this to 1. Default is unlimited.
> errorlevel:
> Will bring up an alert box displaying Javascript errors. This is very helpful for debugging purposes. Possible level values are: warning, error, fatal, none. default is 'none'.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (MYFACES-2174) MyFaces 2.0 AJAX API extension proposal

Posted by "Ganesh Jung (JIRA)" <de...@myfaces.apache.org>.
     [ https://issues.apache.org/jira/browse/MYFACES-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ganesh Jung updated MYFACES-2174:
---------------------------------

    Status: Patch Available  (was: Open)

> MyFaces 2.0 AJAX API extension proposal
> ---------------------------------------
>
>                 Key: MYFACES-2174
>                 URL: https://issues.apache.org/jira/browse/MYFACES-2174
>             Project: MyFaces Core
>          Issue Type: Sub-task
>          Components: JSR-314
>    Affects Versions: 2.0.0-alpha
>         Environment: browser independent javascript
>            Reporter: Ganesh Jung
>             Fix For: 2.0.0-alpha
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Here's the proposal for MyFaces 2.0 extensions to the JSR 314 AJAX API:
> proposed API (all additional attribute are optional, so spec conformant requests are still supportet):
> jsf.ajax.request(this, event, {execute: (componentIds), render: (componentIds), myfaces: {pps: (true/false), queuesize: (int), errorlevel: (warning/error/fatal)})
> And here is what the additional attributes are meant to do:
> pps:
> If set to true, the PPS (partial page submit) feature becomes active. Only the elements numbered in attribute execute will become submitted.
> queuesize:
> The desired size of the request queue. For most applications it makes sense to set this to 1. Default is unlimited.
> errorlevel:
> Will bring up an alert box displaying Javascript errors. This is very helpful for debugging purposes. Possible level values are: warning, error, fatal, none. default is 'none'.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.