Internal Ajax API and reducing page size
I used simplified
http://livedemo.exadel.com/richfaces-demo/richfaces/dataTable.jsf?tab=editDataTable&cid=7002311
sample.
modifications:
- added short ids to table and form (f and dt) in order to optimize page size.
- removed all the columns except one which contains links.
so the column contains:
<a4j:commandLink ajaxSingle="true" id="dlink" limittolist="true" requestDelay="1000"
timeout="10000">
<h:graphicImage value="/images/icons/delete.gif" style="border:0" />
<f:setPropertyActionListener value="#{row}"
target="#{dataTableScrollerBean.currentRow}" />
</a4j:commandLink>A4J.AJAX.Submit('f',event,{'implicitEventsQueue':'f:dt:0:dlink'
,'similarityGroupingId':'f:dt:0:dlink',
'parameters':{'f:dt:0:dlink':'f:dt:0:dlink','ajaxSingle':'f:dt:0:dlink'} ,
'containerId':'f:j_id560','timeout':10000,'requestDelay':1000} );
return false;
Some time ago we told about possible parameters count reducing and after investigation it appeared that current set is required and no parameters could be cut.
And i agree that if in 4.x where we should provide api like rf.ajax.request(...) as public for the users - we should keep such readable notation. But how about small enchancement just for internal usage:
we could implement some internal api which will be just mapping to that public api functions but which wil use shorten parameters names. Example:
rf.req('f',event,{'ieq':'f:dt:0:dlink',
'sgi':'f:dt:0:dlink',
'p':{'f:dt:0:dlink':'f:dt:0:dlink','as':'f:dt:0:dlink'} ,
'cId':'f:j_id560','to':10000,'rd':1000} );
return false;
Length of the string reduced for 32.7 percents. (82 bytes). For that livedemo example with table contains 20 rows and 2 links inside it's 3.2 kb html code reduce. And let's consider cases(editable tables) where we have not only controls in last column but some supports in columns with inputs. In such cases page size reducing could be much more notable.
Talking to the guy who worked at one of the internal projects optimization I found that he used parametrized jsFunction and called it from inside the table instead of a4j:supoprt or a4j:command* using in order to avoid such long calls strings at all. But by implementing such internal methods we could add some default optimizations for the guys who just using our controls in heavy iteration components.
