Glen, >>inline feedback
On Wed, Aug 7, 2013 at 1:15 AM, Glen Mazza <glen.ma...@gmail.com> wrote: > Hi Dirk, some comments and a question: > > > On 08/04/2013 05:49 PM, Dirk Frederickx wrote: > >> Hi all, >> >> I recently added WRO4J to the build chain of JSPWIKI. (see >> https://issues.apache.org/**jira/browse/JSPWIKI-761<https://issues.apache.org/jira/browse/JSPWIKI-761> >> for more details) >> >> The main goal is the introduction of a proper build system for the JS and >> CSS files, allowing to move away from the current monolithic JS and CSS >> files, and break them up in smaller files. >> > > Larger files are not necessarily bad, from the wro4j website itself: > https://code.google.com/p/**wro4j/wiki/Introduction<https://code.google.com/p/wro4j/wiki/Introduction> > : > > "It is common knowledge that it is faster to serve one large file rather > than two smaller ones, because of increased HTTP negotiation and the fact > that most browsers only keep two connections open to the same host at any > given time. The purpose of*wro4j*project is to reduce the number of > requests needed to load a page and the amount of data to transfer to > clients, achieving drastic improvement of loading times. The resources can > be benefit also from minification and compression." > > >> Actually, the whole idea is to *reduce* the number of js and css files at runtime. In general, this improves the performance of page loads. >> Today a normal page view in jspwiki loads at least 4 JS files: mootools.js, jspwiki-common.js, jspwiki-commonstyles.js and prettify.js. With WRO4J, we bring this down to 2 JS files: mootools.js and jspwiki-common.js. >> For now, I propose to keep the mootools.js library separately so that you can still opt to load it via a CDN, allowing it to be even loaded from the browser cache. >> At DESIGN time, however, working on a monolithic JS or CSS is not optimal. Breaking these source files up in smaller pieces will promote modularity, code organisation, reduce complexity, and overall improve maintainability... (and other goodies for developers) > > >> JSPWiki-797 and JSPWIKI-798 are created to track further progress on the >> refactoring of the javascript and stylesheets of JSPWIKI. >> > > Is it your intention to use wro4j at *runtime* or at *buildtime* to merge > the now-split-up CSS and JS files back into one? wro4j supports both. The > latter I presume would be faster for a running JSPWiki, and I guess the > direction we should go, or? > > >> For now, I propose to use wro4 only at BUILDTIME. For production installations, this would be the best approach anyway. (although the impact at RUNTIME is probably limited, since wro4j caches all generated resources) >> One of the main advantages for using wro4j at RUNTIME, is that the wro4j filter also GZIP's the JS and CSS files. This has an enormous impact on the size of these files, and we should definitely consider to add this to JSPWiki in the future. ( either through the wro4j filter or in another way ) > Related issue, a lot of our JavaScripts and CSS files aren't being used, > for example, the FCKEditor stuff, which doesn't presently work (and needs > to be upgraded to CKEditor anyway.) Regardless of whether we use wro4j or > not, I would like to see us pulling out CSS and JS files that are not being > used with the default deployment (*and* cannot be activated from the > UserPreferences page), and putting them in a separate folder not part of > the build or deployment process (or deleted if it's old). Our standard > JSPWiki WAR should just have those CSS and JS files callable by the running > application, I would think. That would also make our builds faster and > less chatty, as we no longer need to see the jslint/jshint JavaScript > complaints on unused files that weren't written by us anyway. > > >> The js and css ( and other) resources (such as .xml files) of the FCKEditor are only used when you activate the wysiwyg editor. This is normally done via the UserPreferences but I noticed this is currently broken. (the "Editor" drop down of the UserPreferences page is not getting populated) >> In general , I would propose that all the assets needed for the FCK editor would reside in the /templates/default/editor directory, rather then being added to the top-level /scripts directory. This way we keep all assets related to the FCK (or CK-editor in the future) together. >> I believe the FCK/CK editor has been a valuable addition to JSPWiki and would not prefer to see it being removed. >> But I agree that upgrading to CKeditor would be preferred. > Thanks, > Glen > > > > > >> >> I'd like to get your feedback/comments for these proposed improvements. >> (preferably in JIRA) If by next friday, there are no objections, I >> consider the proposed way forward accepted. >> >> >> As this change only affects the build system of jspwiki, I assume a formal >> vote is not necessary. >> >> >> >> Txs, >> dirk >> >> >
