On 9/4/07, David Bernard <[EMAIL PROTECTED]> wrote:
> Right to use it, you provide readers, writers, an ErrorReporter and options
> (line-break or not, munge or not, js warning or not,...).
> But as Julien (authors of YUI-Compressor) wrote : the compressor is resource
> consumming and not made to
Sorry I would say : I did a mistake. Oupss
David Bernard wrote:
I didn't a mistake, it's not "a possible advantage".
But what is your opinion about a source stream selector ?
/david
Johan Compagner wrote:
you where talking about Apache and serving it as static resources
So then the urls
I didn't a mistake, it's not "a possible advantage".
But what is your opinion about a source stream selector ?
/david
Johan Compagner wrote:
you where talking about Apache and serving it as static resources
So then the urls should he rewritten because /resources/ is mapped to
wicket
joha
you where talking about Apache and serving it as static resources
So then the urls should he rewritten because /resources/ is mapped to
wicket
johan
On 9/4/07, David Bernard <[EMAIL PROTECTED]> wrote:
>
> I didn't suggest to change the url of resources, in the code we always I
> want .
I didn't suggest to change the url of resources, in the code we always I want
.js. And the url to request the resource is the same.
I suggest to select the stream to return :
* select form cache, cache dir, jar,...
* select version (to allow management of version => -major.minor.bugfix.js
i don't think that will work very easily because the component will make
ResourceReferences to its internal css and js files
and will be outputted as shared resources. Then all those urls should also
be redirected.
johan
On 9/4/07, David Bernard <[EMAIL PROTECTED]> wrote:
>
> An other solution (
An other solution (stupid ?) :
* at build-time (of the war)
* scan all the jars and source to find js and css
* extract/minified/compress into a cache directory
* include the cache directory into the webapp
* at runtime
* when a resource is requested, it search into the cache directory bef
I agree. But currently using a custom compressor for javascript and CSS need to
change the source and replace JavascriptResourceReference by
CustomCompressedResourceReference (or somthing else).
Except if support of CustomCompressor is integrated into existing core Resource.
https://issues.apach
don't know if that is really feasible to do.
because then we have to scan through the complete classpath for resources
like js and css
and then compress them all and keep a reference to that compression all the
time thats could be quite a waste.
it all depends on how long it really takes
johan
Yes simpler and automatic if all run fine.
I like to avoid late compilation/interpretation like JSP.
Is it possible to do it at start-up time (force the compression and caching) of
the webapp and to stop the start if something break ?
Eelco Hillenius wrote:
I use a other approach for the same
yeah but a one time hit shouldn't be to much of a problem..cache the result
The problem with wicket is that you don't know exactly where everything is
coming from..
They could be in all kinds of jars so if you want compression it should be
runtime else you need to go over
all the jars and code you
Right to use it, you provide readers, writers, an ErrorReporter and options
(line-break or not, munge or not, js warning or not,...).
But as Julien (authors of YUI-Compressor) wrote : the compressor is resource
consumming and not made to run on-fly.
/David
Johan Compagner wrote:
thats a prett
thats a pretty nice one, it also compresses CSS. It does depend on rhino and
another jar
so its a total of 3 jars so it should be outside the wicket core or
extentions (a project by itself?)
also all the examples that i see are with the command line and input
filenames
i hope it has a interface whe
And if yui uses that one for there own then yes it works pretty good, code
is hardly readable anymore ;(
On 9/3/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> On 9/1/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
> > Well, I certainly didn't want to reinvent the wheel. But all existing
> > solutio
and in the mean time your code is obfuscated and hard to read/copy :)
On 9/3/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote:
>
> Most of the "good" minification libraries do more than just stripping
> comments. usual features include:
> * strip comments
> * rename local variables to save space (ex: my
On 9/1/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
> Well, I certainly didn't want to reinvent the wheel. But all existing
> solutions I was able to find either relied on a third part library
> (shrinksafe) or had license not compatible with ASL. So I just wrote a
> simple stripper. I think it still
> I use a other approach for the same goal (http optimization), to avoid
> minification and compression at run-time do it at compile-time.
But if you do it at run-time once and cache the results (like we do)
you can keep things a lot simpler and automatic.
Eelco
On 9/3/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote:
> Also, for what it's worth, the current wicket JavascriptStripper breaks on
> my app. I'm using prototype and scriptaculous, and when I enable the
> current wicket compression, my app no longer works. I get javascript errors
> left and right.
>
>
Most of the "good" minification libraries do more than just stripping
comments. usual features include:
* strip comments
* rename local variables to save space (ex: myLocalVariable becomes a)
* collapse string concatination. this is a nice performance enhancement
that will change multiline/verbos
Yeah, we strip commends, there are tools that can also reduce things like
local variable names, etc.
-Matej
On 9/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>
> well yeah, but we _already_ strip comments, that is why i was wondering
> what
> the point of a plugin-minification would be.
>
> -ig
well yeah, but we _already_ strip comments, that is why i was wondering what
the point of a plugin-minification would be.
-igor
On 9/3/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
>
> Well, I don't find it surprising. Lot of javascript code are comments, and
> if you strip them out, you have less
Hi,
I use a other approach for the same goal (http optimization), to avoid
minification and compression at run-time do it at compile-time.
It's what I try do, :
* I first implement the yuicompressor-maven-plugin.
* now I need to develop the ResourceSelector that choose the rigth file to
return
Well, I don't find it surprising. Lot of javascript code are comments, and
if you strip them out, you have less content to compress, thus the numbers
are smaller. You can set as high compression as you want, but the comments
still make difference. (Not so much for whitespaces imho)
-Matej
On 9/3/
still seems a bit counterintuitive to me. maybe gzip doesnt use a very high
compression setting to trade off time. but oh well, numbers dont lie.
-igor
On 9/2/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote:
>
> Dean Edwards also had a recent blog posting on this topic. His
> recommendation is to com
Dean Edwards also had a recent blog posting on this topic. His
recommendation is to compress and gzip content whenever possible.
http://dean.edwards.name/weblog/2007/08/js-compression/
On 9/2/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote:
>
> gzip and minifing *do* go together.
>
> Here's a really
gzip and minifing *do* go together.
Here's a really great site that compares the different approaches.
http://compressorrater.thruhere.net/
minifing before gziping shows a considerable reduction in content size
(usually between 5-10 percent).
On 9/2/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
so we should do one or the other, i got the impression that his tool
complained because js was not minified even though it was gzipped.
-igor
On 9/2/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
>
> For certain browsers (even IE6) the GZIP compression doesn't work. And if
> you have a lot of javasc
For certain browsers (even IE6) the GZIP compression doesn't work. And if
you have a lot of javascripts (YUI, dojo, ...) it can make a difference.
-Matej
On 9/2/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>
> ermwhat exactly is the point of minifing AND gziping javascript or
> anything else?
ermwhat exactly is the point of minifing AND gziping javascript or
anything else? if you take a zip file and then zip it again do you get a
smaller file?
-igor
On 9/1/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote:
>
> excellent! Thanks Matej. Let me know if you have any other ideas on
> this.
>
excellent! Thanks Matej. Let me know if you have any other ideas on this.
As soon as there's an abstraction in place, i'll be happy to create a
wicketstuff project with the dojo (and maybe YUI) compressors!
https://issues.apache.org/jira/browse/WICKET-918
On 9/1/07, Matej Knopp <[EMAIL PROTECT
I don't see reason why not, you can create a RFE in jira.
-Matej
On 9/2/07, Ryan Sonnek <[EMAIL PROTECTED]> wrote:
>
> Creating a pluggable interface for this would allow for non-ASL solutions
> to
> be hosted through wicket-stuff projects. The default implementation could
> stay as it is today.
Creating a pluggable interface for this would allow for non-ASL solutions to
be hosted through wicket-stuff projects. The default implementation could
stay as it is today.
On 9/1/07, Matej Knopp <[EMAIL PROTECTED]> wrote:
>
> Well, I certainly didn't want to reinvent the wheel. But all existing
Well, I certainly didn't want to reinvent the wheel. But all existing
solutions I was able to find either relied on a third part library
(shrinksafe) or had license not compatible with ASL. So I just wrote a
simple stripper. I think it still helps a lot, I didn't want to build a
perfect stripper.
I've been running my app through the YSlow firefox plugin, and have been
*very* impressed on how wicket does the "right thing" most of the time (ex:
gzip css and javascript). nice work guys!
While digging through the YSlow feedback, it suggested that the javascript
should be "minified". This led
34 matches
Mail list logo
