About reducing size of js: (apart from compression) Approx. 1/3 of the JS is related to 'dynamic styles' which may or may not be applicable to certain pages. Certain styles are less essential to the basic wiki functionality. (we may even consider to remove them from the core jspwiki package)
At the server, the DOM tree could be pre-processed to check which %%styles are used. The js could be split in several pieces which, depending on the needed styles, would be loaded to the client. This could be done in a pluggable way * jspwiki-common.js is always loaded * jspwiki-extras.js is only loaded in case some %%styles are present This would also allow for other users to contribute js-plugins. - - - - About moving more stuff to the server: The current jspwiki-common.js is build up in a modular way. These js modules all follow a similar pattern. Most of them have some 'on-page-load' functionality which performs some preparation work such as dom manipulation, registering event-handlers. The remaining part contains event handlers, ajax routines, visual effects, which can only be executed in a browser on the client. In some cases it would be feasible to move the preparation block to the server. Eg. edit-section links could be added by the server iso the client, DOM manipulation to convert an unordered list into a collapsible list could be done in the server, etc. The main driver for this is performance. Allthough Janne is complaining about performance, my experience so far is that the DOM preparation is pretty fast. JS is mostly cached, execution 'on-page-load' (even on IE) is also fast. ==> can we have some feedback on this from other people on this mailing-list ...? For some cases (such as mobile devices), I think we should consider to make a dedicate template. Such simplified template would not contain advanced effects , ajax autocompletion searches, attachment viewers, left-menu's, tabs, breadcrumbs, etc... and better fit to the limitation of screen size, and mouse/keyboard/touch-screen input. Eventually, the standard jspwiki package would have 2 default-templates : (i) feature rich, targetting desktops with A-grade browsers, and (ii) a simplified template targetting mobile-devices, iphone, devices on slow networks. I don't think Stripes will change that picture. It'll sure make template writing less complex, but will still need client side javascript to achieve certain functionalities. And require us to find a good balance between server/client side. dirk On Sat, Apr 5, 2008 at 9:10 PM, Janne Jalkanen <[EMAIL PROTECTED]> wrote: > > I guess the question is if there are any refactorings that we could do now? > Something that will end up in ActionBeans in 3.0? > > /Janne > > > > On 5 Apr 2008, at 20:53, Andrew Jaquith wrote: > > > This is a key reason I want to start using Stripes... Will force some > refactoring... > > > > On Apr 5, 2008, at 9:19, Janne Jalkanen <[EMAIL PROTECTED]> wrote: > > > > > > > Folks, > > > > > > I'm getting a bit worried about all the Javascript we have in the > current template. First of all, it's quite a lot of stuff to send around > (several tens of kilobytes, even when compressed); and second, it's taking > quite a lot of processing time, as the DOM tree gets walked quite often. It > is for example choking my phone browser pretty thoroughly, and also taking > quite a lot of memory. > > > > > > Also, it relies quite a lot on the default template and default editor, > which might make it a bit complicated for people to add the additional stuff > to other templates or editors. > > > > > > So, the question is: what kind of functionality we should and could move > to the back-end? I'm thinking of common tasks, some processing of the DOM > tree (which could take advantage of the DOM tree caching that we have), and > in general things that have been found to be good and should be shared > across all templates and editors. > > > > > > Also, the advantage would be that if it were done in Java in the > back-end, it would make it easier for people to contribute to. I'll have to > confess that a lot of the JS stuff is going above my head, so I can't really > contribute - I fear that I break something. The fact that we don't have an > unit test suite for the JS worries me, too. > > > > > > Any suggestions? Dirk, you know the stuff better than anyone else. Do > you have any suggestions on the stuff that we should start working on > transferring? > > > > > > /Janne > > > > > > >
