You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Dirk Frederickx <di...@gmail.com> on 2013/08/04 23:49:38 UTC
wro4j
Hi all,
I recently added WRO4J to the build chain of JSPWIKI. (see
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.
JSPWiki-797 and JSPWIKI-798 are created to track further progress on the
refactoring of the javascript and stylesheets of JSPWIKI.
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
Re: wro4j
Posted by Glen Mazza <gl...@gmail.com>.
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 <gl...@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
>>
Re: wro4j
Posted by Ichiro Furusato <ic...@gmail.com>.
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 <gl...@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
>
Re: wro4j
Posted by Glen Mazza <gl...@gmail.com>.
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
Re: wro4j
Posted by Dirk Frederickx <di...@gmail.com>.
Glen,
>>inline feedback
On Wed, Aug 7, 2013 at 1:15 AM, Glen Mazza <gl...@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
>>
>>
>
Re: wro4j
Posted by Juan Pablo Santos RodrÃguez <ju...@gmail.com>.
Hi,
I'm +1 on this. We're beginning to use wro4j at work for some simple cases,
only compression and minification, and I'd be interested in seeing some
more complex use cases :-)
thx,
juan pablo
p.d.: @Glen, unless I'm mistaken, we're currently using wro4j at
build-time, via wro4j-maven-plugin, run-time requires
ro.isdc.wro.http.WroFilter to be declared in web.xml
On Wed, Aug 7, 2013 at 1:15 AM, Glen Mazza <gl...@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."
>
>
>
>> 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?
>
> 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.
>
> 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
>>
>>
>
Re: wro4j
Posted by Glen Mazza <gl...@gmail.com>.
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 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:
"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."
>
> 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?
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.
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
>
Re: wro4j
Posted by Dirk Frederickx <di...@gmail.com>.
Harry,
You may be able to speed things up by skipping the minification step during
development or test builds by using the -Dminimize=false option.
The merging will still be needed as soon as we start to break the js and
css files into smaller chunks.
I wonder if maven would be smart enough to skip the merging when no changes
are done to the source files. So far, I have not seen this happening.
dirk
On Mon, Aug 5, 2013 at 6:56 AM, Harry Metske <ha...@gmail.com> wrote:
> +0.5
>
> I have very little knowledge/experience with js and css. I trust what you
> say is the right thing to do.
> It would be nice to have an option to skip this wro4j step when running
> (individual) mvn tests, cause the wro4j step takes quite a bit of time.
>
> kind regards,
> Harry
>
>
>
> On 4 August 2013 23:49, Dirk Frederickx <di...@gmail.com> wrote:
>
> > Hi all,
> >
> > I recently added WRO4J to the build chain of JSPWIKI. (see
> > 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.
> >
> > JSPWiki-797 and JSPWIKI-798 are created to track further progress on the
> > refactoring of the javascript and stylesheets of JSPWIKI.
> >
> >
> > 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
> >
>
Re: wro4j
Posted by Harry Metske <ha...@gmail.com>.
+0.5
I have very little knowledge/experience with js and css. I trust what you
say is the right thing to do.
It would be nice to have an option to skip this wro4j step when running
(individual) mvn tests, cause the wro4j step takes quite a bit of time.
kind regards,
Harry
On 4 August 2013 23:49, Dirk Frederickx <di...@gmail.com> wrote:
> Hi all,
>
> I recently added WRO4J to the build chain of JSPWIKI. (see
> 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.
>
> JSPWiki-797 and JSPWIKI-798 are created to track further progress on the
> refactoring of the javascript and stylesheets of JSPWIKI.
>
>
> 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
>