im not sure we could help in the cases where you have dynamic header
contributors, like you say you would either have to specify them up front
(ie add them into the page not the panel, breaking encapsulation) or just
serve via the normal header contributor.
But i dont see how this would result
It's not the pages that have these files. Let's say I have a page that
uses jquery and a textfield with a button that toggles tinymce.
If we do what you say then there are two possible files: jquery and
jquery+tinymce.
Than let's say I add Ajax to the page, now there are 6 possibilities
There is yet another thing to consider. Iphone doesn't cache resources
bigger than 25kb (after unzipping). So instead of grouping files
together sometimes it even might be appropriate to split them...
-Matej
On Wed, Sep 3, 2008 at 4:11 PM, [EMAIL PROTECTED] wrote:
It's not the pages that have
I see your point, essentially we have 1 (relativity large) bundle file per
page, and if you have 5 pages which use jquery, tinymce and ajax then you
are worse off, since the normal way you would have already cached the 3
individual files (this is what you meant right?)
Maybe there is some way to
Hmmm. As you say, there's no easy one-size-fits-all.
There is an obvious improvement you could make, though. All JS/CSS
contributions initially rendered on the home page could be batched up. This
will typically provide the biggest improvement anyway. You could then keep a
reference to this batch,
On Wed, Sep 03, 2008 at 04:34:34PM +0100, Al Maw wrote:
I'd even go so far as to remove the need for HeaderContributor code entirely
in 80% of the cases.
Wicket could automatically pick up css and js files that are named the same
as your component.
MyComponent.java
MyComponent.html
in html:
html
head
wicket:head
wicket:link
link href=MyComponent.css rel=stylesheet /
script src=MyComponent.js type=text/javascript
/script
/wicket:link
/wicket:head
/head
body
wicket:panel
some foo
/wicket:panel
/body
/html
Which has the added bonus of being previewable.
Martijn
On Wed,
Ignoring the iPhone - not everyone has that as a target platform - the
bruteforce method of packaging everything into one file isn't that
bad. The initial bandwidth hit is outweighed be reducing requests to
one (or two, one js, one css file). That means the first page loads a
bit longer, which is
wicketstuff-merged-resources is now available in JIRA:
http://wicketstuff.org/jira/browse/WMR
and from wicketstuff maven repo:
repositories
repository
idwicket-snaps/id
urlhttp://wicketstuff.org/maven/repository/url
snapshots
Thanks Stefan! Just removed my local checkout and it works fine.
Jörn
On Tue, Sep 2, 2008 at 8:46 AM, Stefan Fußenegger
[EMAIL PROTECTED] wrote:
wicketstuff-merged-resources is now available in JIRA:
http://wicketstuff.org/jira/browse/WMR
and from wicketstuff maven repo:
repositories
The problem of breaking encapsulation:
I did some work on this problem on my own a few months ago, my solution was
to use a header contrib manager, and instead of adding files with a header
contributer i add them to the manager, then get a single contributer per
page from the manger.
for
problem with this is that pages can have dynamic components which
dynamic header contributions.
so either you have to somehow collect all possible header
contributions from all possible component combinations - breaking
encapsulation in the process, or you have to do what you do - ending
up with
honestly, no, I didn't. however, using last modified times still results in
an HTTP request and a 304 Not Modified reply. better than nothing, but
client-side caching is still preferable.
regards
Peter Ertl wrote:
@stefan: did you take into account
getApplication
you're right with the encapsulation, but i feel that resource versioning (and
aggressive client side caching) could be a nice addition to wicket. but
maybe sombody can think of another way to reduce (merge) resources without
breaking encapsulation ...
btw, resource versioning also works with
That's not true.
this settings will generate urls like:
/resources/[package+class]/javascript.js?lm=[lastmodified]
read it again : add Last Modified Time To Resource Reference Url
getApplication
().getResourceSettings
().setAddLastModifiedTimeToResourceReferenceUrl(true)??
It will
Okay, sorry, you're right. Too bad, I didn't ever stumble upon this option.
However, changing filename instead of using query string has certain
advantages, see
http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
Furthermore, setting this option does not effect
I totally agree that having the version in the filename and not in the
query string will be a-lot-better.
Just wanted to point you to that option so you can include it in your
excellent analysis on caching *thanks* :-)
People can use that option right now and get a more decent version
I thing we should look at what that append to url does, because i dont
like the query string either, i also rather have it in the url path
itself.
Also such a resource cache duration can be added. But i also rather
have it configured by resoure(reference) like
On Fri, Aug 29, 2008 at 9:41 AM, Peter Ertl [EMAIL PROTECTED] wrote:
I totally agree that having the version in the filename and not in the query
string will be a-lot-better.
Just wanted to point you to that option so you can include it in your
excellent analysis on caching *thanks* :-)
Sounds promising ... and little mysterious ;) Any concrete plans/ideas so
far?
Matej Knopp-2 wrote:
On Fri, Aug 29, 2008 at 9:41 AM, Peter Ertl [EMAIL PROTECTED] wrote:
I totally agree that having the version in the filename and not in the
query
string will be a-lot-better.
Just wanted
Code is now available through wicketsuff:
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/
wicketstuff-merged-resources and
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/
Here is a first patch for the RevisionVersionProvider:
Index:
src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
===
---
why don't you open up an issue in JIRA?
Am 29.08.2008 um 12:22 schrieb Jörn Zaefferer:
Here is a first patch for the RevisionVersionProvider:
Index: src/main/java/org/wicketstuff/mergedresources/versioning/
RevisionVersionProvider.java
Good point, I forgot that wicketstuff has its own JIRA installation.
Though the entry for the project is missing. Let me know once its
there, and I'll create the report.
Jörn
On Fri, Aug 29, 2008 at 12:26 PM, Peter Ertl [EMAIL PROTECTED] wrote:
why don't you open up an issue in JIRA?
Am
just applied your patch
could somebody please create wicketstuff-merged-resources in JIRA and
teamcity?
Jörn Zaefferer-2 wrote:
Here is a first patch for the RevisionVersionProvider:
Index:
src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
Again, great work Stefan!
The basics already work fine, allowing me to keep a maintenance
friendly style of development while heavily optimizing frontend
performance.
The biggest isse now is the public API: I have to duplicate a lot of
information in the application and the page/component
sfussenegger now has access to wicketstuff...
i dont know which parts should go into wicket itself, i can tell you
that the part where you merge the files by listing them out upfront is
probably not going to make it in because it breaks encapsulation...
-igor
On Thu, Aug 28, 2008 at 2:59 AM,
@stefan: did you take into account
getApplication
().getResourceSettings
().setAddLastModifiedTimeToResourceReferenceUrl(true)??
Cheers
Peter
Am 28.08.2008 um 18:20 schrieb Igor Vaynberg:
sfussenegger now has access to wicketstuff...
i dont know which parts should go into
nice
we are also taking efforts in optimizing the webapp
as we serve the resources (images/css/js) using 3rd content provider, our
approach is different from your wicket-focus turning; but it indeeds give me
some insight, thanks
we also want to merge the css/js files, but after thinking
29 matches
Mail list logo
