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 <glen.ma...@gmail.com> 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 >
