On 08/07/2013 05:47 AM, Dirk Frederickx wrote:
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 )
We would have to test that it would provide a benefit, because the
CSS&JS will already be compressed/minimized so perhaps not much gained.
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)
Oh, I didn't realize that, you *can* activate the wsyiwyg editor via a
running JSPWiki application (providing it worked), yes, then it needs to
remain in the standard distribution.
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.
+1
Regards,
Glen
