[
https://issues.apache.org/jira/browse/WICKET-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Attila Király updated WICKET-1790:
----------------------------------
Attachment: WICKET-1790.patch
Attaching a patch that resolves this issue.
It's mainly a refactor of the original code to generate 3 different javascript
instead of 1.
1, the loading, initalizing javascript with some new helper functions is now
generated only once per page.
2, localization strings are generated only once per localization per page.
Because most application use the same localization for all datepickers in a
page in practice this means that localization strings are only generated once
per page. This is a reduction not only in generated js bytes but also in server
side cpu cycles.
3, datepicker init script which is generated for every datepicker on page is
greatly reduced.
I made some tests to see how much is the size reduction. These were measured in
deployment mode with wicket javascript compressor working.
The original 1.5M3 code generated around 1830 bytes of javascript per
datepicker. The new code generates 340 (+ once the js generated by 1, and 2,).
This means that there is no real difference if there is only 1 datepicker in
page. But with 2 datepickers the reduction is 35% with 10 it is 72%.
The patch is made against wicket trunk, revision 1053118 (somewhere between the
already released 1.5M3 and the upcoming 1.5M4). Junit tests in the datepicker
submodule pass but for the first time junit needs to be run with
"-Dwicket.replace.expected.results=true" because
/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatesPage1_ExpectedResult.html
needs to be regenerated.
Hopefully somebody in the wicket team can spare some time to review the patch
and apply it if it is found good enough.
> DatePicker javaScript should be optimized. Currently DatePicker generates
> 3000 bytes of javascript for each date field.
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-1790
> URL: https://issues.apache.org/jira/browse/WICKET-1790
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-extensions
> Affects Versions: 1.4-M1
> Reporter: Martin Makundi
> Attachments: WICKET-1790.patch
>
> Original Estimate: 0.08h
> Remaining Estimate: 0.08h
>
> Currently DatePicker generates 3000 bytes of javascript per each date field
> (more specifically per each date field having DatePicker).
> If you have a table with 2 date columns and 10 rows this means 60000 bytes
> excess HTTP traffic. And it shows. It slows down page rendering significantly.
> DatePicker javaScript should be optimized. I myself am not a javascript
> wizard, I do not know which hooks could serve this change. But I know where
> the problem is: each datePicker component is given its own initializer
> methods instead of using parametrized method calls:
> // block 1
> initproject__employee__startdate123 = function() {
> Wicket.DateTime.init( {
> widgetId: "project__employee__startdate123", <---------- this
> should be suitably parametrized
> componentId: "project__employee__startdate123", <---------- this
> should be suitably parametrized
> ....
> }
> // block 2
> if (wicketCalendarInitFinished) {
> initproject__employee__startdate123(); <---------- this should be suitably
> parametrized
> } else {
> wicketCalendarInits.push(initproject__employee__startdate123); <----------
> this should be suitably parametrized
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
