JS & CSS compression may be overrated today anyway, in a world of
super-fast internet and YouTube videos, a few fat JS & CSS files may
take up the same amount of bandwidth as three seconds of a video, so it
may not be worth spending much time over. (FWIW, AFAIK Roller doesn't
do any compression.) But if wro4j provides other benefits, it's OK with me.
However, the roughly 30-45 second delay every time we do an mvn test
-Dtest=xxxx just to have the JS and CSS get re-compressed and re-linted
from scratch is very irritating/draining (and was happening even before
wro4j.) With my last patch I had to do a lot of debugging and these
delays are taking their toll. Maybe with WAR overlays (?) we can pull
out the CSS & JS and put it in a separate submodule so those working
with the Java code don't have to keep getting delayed by this processing.
Glen
On 08/08/2013 06:52 PM, Ichiro Furusato wrote:
Hi,
I don't have the time right now to dig into what you guys are proposing
with wro4j so I
can only add a cautionary tale to the table. I imagine that the vast
majority of JSPWiki
users (i.e., installers) will be modifying the PlainVanilla theme to create
a style that
matches their individual requirements, so anything that changes the status
quo (eases
that or makes it more complicated) needs to be *very* carefully considered.
We have
over the years done quite a few themes (some quite complicated that even
involved
JSP changes) and don't find it particularly onerous to work with a base
jspwiki.css and
a skin.css file using the theme/skin structure. If this change makes that a
lot more
difficult it will likely turn off a lot of people from using JSPWiki, if it
raises the bar to
being able to make a wiki look the way one desires. I don't think
performance is
generally an issue here - the wiki isn't slowed down much by delivering
what is in
actuality a rather small stylesheet.
Anyway, my 2c.
Ichiro
On Thu, Aug 8, 2013 at 11:31 PM, Glen Mazza <[email protected]> wrote:
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
