Yep! There is no issue till we don't prove there is one .. and them we also need to prove gain obtained with new solution justify added complexity!
On Fri, Jan 25, 2013 at 2:54 PM, Martin Grigorov <mgrigo...@apache.org>wrote: > 1. Prove that it is slow now > 2. Implement the optimized way > 3. Prove that it is faster enough than the current way so we can agree to > maintain the more complex code > 4. Write some tests > 5. At the end I'll be happy to commit your patches :-) > > > On Fri, Jan 25, 2013 at 3:48 PM, Nick Pratt <nbpr...@gmail.com> wrote: > > > Couldn't we make some of these additional optimizations part of the > > deployment options, similar to how other things are enabled in > development > > vs deployment? > > > > N > > > > On Fri, Jan 25, 2013 at 8:42 AM, Martin Grigorov <mgrigo...@apache.org > > >wrote: > > > > > On Fri, Jan 25, 2013 at 3:30 PM, Ernesto Reinaldo Barreiro < > > > reier...@gmail.com> wrote: > > > > > > > Hi Martin, > > > > > > > > Thanks for your answer! > > > > > > > > On Fri, Jan 25, 2013 at 1:51 PM, Martin Grigorov < > mgrigo...@apache.org > > > > >wrote: > > > > > > > > > Hi Ernesto, > > > > > > > > > > Since https://issues.apache.org/jira/browse/WICKET-4881 (6.4.0) > > > Wicket > > > > > combines all JS snippets > > (AjaxRequestTarget#append/prependJavaScript()) > > > > > into at most one <evaluate-priority> and one <evaluate>. So this > > > > > optimization is in place in core. > > > > > > > > > > > > > > Yes this is one big step on such optimization! > > > > > > > > Another step could be collecting all > > > > > > > > > > > > > > > > > > Wicket.Ajax.ajax({"u":"./list?3-1.IBehaviorListener.0-entities-entitiesList-bictables-1-actions-edit","e":"click","c":"editf6"}); > > > > .... > > > > > > > > into a single > > > > > > > > Wicket.Ajax.ajax([{a1}, {a}, ... {aN} ]); > > > > > > > > For this case you don't gain much (just removing a "few" > > > > Wicket.Ajax.ajax))... > > > > > > > > Or you can collect them by "event" and do something like > > > > > > > > Wicket.Ajax.ajax([{e:"click",[{a1}, {a}, ... {aN}]}, {e:"onchage", > > [{b1}, > > > > ... {bN}]]}, ...]); > > > > > > > > in this case you get rid of a lot of repeated e: "click" and > > e:"onchage". > > > > Of course this will only pay of for page with lots of links and so > > on... > > > > > > > > In our use case for the date picker this a big optimizations because > > > there > > > > is a lot of "static" data that is repeater over and over (I so you > > > already > > > > rolled out something like that at the client side for 6.0.x date > > picker). > > > > > > > > > > > I prefer to keep it simple and easy for maintain and debug. > > > If we have an evidence that it is really slow then we can think on > > > optimizations. > > > > > > > > > > > > > > > For non-Ajax requests you can use > > > > > org.apache.wicket.markup.html.IHeaderResponseDecorator. You can > again > > > > > collect all JS in a thread local (or in RequestCycle's metadata) > and > > > > > contribute it as optimized JS call just before > > HeaderResponse#close(). > > > > > I.e. instead of having N entries in Wicket.Event.add(window, > > > 'domready', > > > > > function() { HERE }) you will have just one (the optimized) entry. > > > > > > > > > > > > > > Thank you very much for the idea! > > > > > > > > -- > > > > Regards - Ernesto Reinaldo Barreiro > > > > Antilia Soft > > > > http://antiliasoft.com/ <http://antiliasoft.com/antilia> > > > > > > > > > > > > > > > > -- > > > Martin Grigorov > > > jWeekend > > > Training, Consulting, Development > > > http://jWeekend.com <http://jweekend.com/> > > > > > > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com <http://jweekend.com/> > -- Regards - Ernesto Reinaldo Barreiro Antilia Soft http://antiliasoft.com/ <http://antiliasoft.com/antilia>
