[ https://issues.jboss.org/browse/RF-10489?page=com.atlassian.jira.plugin.s... ] nimo stephan updated RF-10489: ------------------------------ Summary: extend "render" and "data" -property of rich:ajax to accept css or jquery like selectors (was: extend render-property of rich:ajax to accept css or jquery like selectors) Description: The JSF2 (RF4) supports ajax out of the box with its render-property. The render-property does only accept one or more server-side compontent ID's. Why does the render-value does not support classes? Or going further, why does the render-value does not support css-or jquery-like selectors? It would be very nice and clean to do something like this: <f:ajax render="$('.myclass)" .../> instead of this: <f:ajax render=":form, :text, :table, :menu" .../> myclass could be act as SERVICE: So I say myclass has the name "update_data_hobbies" and with that name I include all its components which should be considered by invoking the service "update_data_hobbies". <f:ajax render="$('.update_data_hobbies)" .../> <h:form class="update_data_hobbies"..> .. </h:form> <h:inputText class"update_data_hobbies"../> <rich:datatable class="update_data_hobbies".../> <!-- and so on.. --> (by the way, it would be cleaner to extract the service-name from the html5 data-attribute, for example data-ajax="update_data_hobbies"). With the ability to enhance the property with css-jquery-like selectors, I can, for example, easily update all my table-elements: <f:ajax render="$('table')" .../> Go one step further, now the developer can maintain all the ajax-cluttered-code easily by searching for the name of the service, namely update_data_hobbies, within the code to get or see all related ajax-components in one step without the need to search by ID. Go two steps further, jboss tools can then easily provide an Editor ("ajax-overview-editor") in which all correlated ajax-calls are viewed by its service. One of the main problems while developing ajax-sites is, that it is not very fast and easy to see and maintain all the components which are affected by ajax-calls. It will become harder, if the affected compontens are cluttered in more than one pages, which can happen when using templating future of jsf/facelets. It is annoying, to limit the render-value by its id, it is annoying, to search all the ID's which are listed in the render-value manually. It would leverage the semantic level of developing and maintain jsf-views by introducing the service "update_data_hobbies" instead of its correlated IDs. JSF has the nice future of relating components in data and render via @ (for example @form which relates the form and its enclosed tags where ajax call is made). However, @ is very limited in selecting tags. But maybe the extend of the functionality of the @-Operator is the way to go. For this reason, I created a future request. was: The JSF2 (RF4) supports ajax out of the box with its render-property. The render-property does only accept one or more server-side compontent ID's. Why does the render-value does not support classes? Or going further, why does the render-value does not support css-or jquery-like selectors? It would be very nice and clean to do something like this: <f:ajax render="$('.myclass)" .../> instead of this: <f:ajax render=":form, :text, :table, :menu" .../> myclass could be act as SERVICE: So I say myclass has the name "update_data_hobbies" and with that name I include all its components which should be considered by invoking the service "update_data_hobbies". <f:ajax render="$('.update_data_hobbies)" .../> <h:form class="update_data_hobbies"..> .. </h:form> <h:inputText class"update_data_hobbies"../> <rich:datatable class="update_data_hobbies".../> <!-- and so on.. --> (by the way, it would be cleaner to extract the service-name from the html5 data-attribute, for example data-ajax="update_data_hobbies"). With the ability to enhance the property with css-jquery-like selectors, I can, for example, easily update all my table-elements: <f:ajax render="$('table')" .../> Go one step further, now the developer can maintain all the ajax-cluttered-code easily by searching for the name of the service, namely update_data_hobbies, within the code to get or see all related ajax-components in one step without the need to search by ID. Go two steps further, jboss tools can then easily provide an Editor ("ajax-overview-editor") in which all correlated ajax-calls are viewed by its service. One of the main problems while developing ajax-sites is, that it is not very fast and easy to see and maintain all the components which are affected by ajax-calls. It will become harder, if the affected compontens are cluttered in more than one pages, which can happen when using templating future of jsf/facelets. It is annoying, to limit the render-value by its id, it is annoying, to search all the ID's which are listed in the render-value manually. It would leverage the semantic level of developing and maintainance by introducing the service "update_data_hobbies" instead of its correlated IDs. For this reason, I created a future request. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/RF-10489?page=com.atlassian.jira.plugin.s... ] nimo stephan updated RF-10489: ------------------------------ Description: The JSF2 (RF4) supports ajax out of the box with its render-property. The render-property does only accept one or more server-side compontent ID's. Why does the render-value does not support classes? Or going further, why does the render-value does not support css-or jquery-like selectors? It would be very nice and clean to do something like this: <f:ajax render="$('.myclass)" .../> instead of this: <f:ajax render=":form, :text, :table, :menu" .../> myclass could be act as SERVICE: So I say myclass has the name "update_data_hobbies" and with that name I include all its components which should be considered by invoking the service "update_data_hobbies". <f:ajax render="$('.update_data_hobbies)" .../> <h:form class="update_data_hobbies"..> .. </h:form> <h:inputText class"update_data_hobbies"../> <rich:datatable class="update_data_hobbies".../> <!-- and so on.. --> (by the way, it would be cleaner to extract the service-name from the html5 data-attribute, for example data-ajax="update_data_hobbies"). With the ability to enhance the property with css-jquery-like selectors, I can, for example, easily update all my table-elements: <f:ajax render="$('table')" .../> Go one step further, now the developer can maintain all the ajax-cluttered-code easily by searching for the name of the service, namely update_data_hobbies, within the code to get or see all related ajax-components in one step without the need to search by ID. Go two steps further, jboss tools can then easily provide an Editor ("ajax-overview-editor") in which all correlated ajax-calls are viewed by its service. One of the main problems while developing ajax-sites is, that it is not very fast and easy to see and maintain all the components which are affected by ajax-calls. It will become harder, if the affected compontens are cluttered in more than one pages, which can happen when using templating future of jsf/facelets. It is annoying, to limit the render-value by its id, it is annoying, to search all the ID's which are listed in the render-value manually. It would leverage the semantic level of developing and maintain jsf-views by introducing the service "update_data_hobbies" instead of its correlated IDs. JSF has the nice future of relating components in data and render via @ (for example @form which relates the form and its enclosed tags where ajax call is made). However, @ is very limited in selecting tags. But maybe, it would be reasonable to extend the functionality and the meaning of the @-Operator as a @-selector. For this reason, I created a future request. was: The JSF2 (RF4) supports ajax out of the box with its render-property. The render-property does only accept one or more server-side compontent ID's. Why does the render-value does not support classes? Or going further, why does the render-value does not support css-or jquery-like selectors? It would be very nice and clean to do something like this: <f:ajax render="$('.myclass)" .../> instead of this: <f:ajax render=":form, :text, :table, :menu" .../> myclass could be act as SERVICE: So I say myclass has the name "update_data_hobbies" and with that name I include all its components which should be considered by invoking the service "update_data_hobbies". <f:ajax render="$('.update_data_hobbies)" .../> <h:form class="update_data_hobbies"..> .. </h:form> <h:inputText class"update_data_hobbies"../> <rich:datatable class="update_data_hobbies".../> <!-- and so on.. --> (by the way, it would be cleaner to extract the service-name from the html5 data-attribute, for example data-ajax="update_data_hobbies"). With the ability to enhance the property with css-jquery-like selectors, I can, for example, easily update all my table-elements: <f:ajax render="$('table')" .../> Go one step further, now the developer can maintain all the ajax-cluttered-code easily by searching for the name of the service, namely update_data_hobbies, within the code to get or see all related ajax-components in one step without the need to search by ID. Go two steps further, jboss tools can then easily provide an Editor ("ajax-overview-editor") in which all correlated ajax-calls are viewed by its service. One of the main problems while developing ajax-sites is, that it is not very fast and easy to see and maintain all the components which are affected by ajax-calls. It will become harder, if the affected compontens are cluttered in more than one pages, which can happen when using templating future of jsf/facelets. It is annoying, to limit the render-value by its id, it is annoying, to search all the ID's which are listed in the render-value manually. It would leverage the semantic level of developing and maintain jsf-views by introducing the service "update_data_hobbies" instead of its correlated IDs. JSF has the nice future of relating components in data and render via @ (for example @form which relates the form and its enclosed tags where ajax call is made). However, @ is very limited in selecting tags. But maybe we can extend the functionality of the @-Operator is the way to go. For this reason, I created a future request. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira