what if the cache knew the actual resource path of the resource also then we can cache login.html, default.html, default_style1.html, default_style2.html independently of what they actually map to...
-igor On Wed, Apr 9, 2008 at 11:41 AM, Johan Compagner <[EMAIL PROTECTED]> wrote: > but then we are back at the original problem that we have many same > resources in the cache > that will be a real memory hog. > > johan > > > On Wed, Apr 9, 2008 at 8:21 PM, Meetesh Karia <[EMAIL PROTECTED]> > wrote: > > > > What about adding the style and variation into the location string when > > it's used as a cache key. That will prevent the problem with the locales, > > but will address the issue below too ... > > > > > > Johan Compagner wrote: > > > > hmm this is now a tricky one.. > > i need to figure out how it should work now.. > > > > > > On Wed, Apr 9, 2008 at 8:04 PM, Meetesh Karia <[EMAIL PROTECTED]> > > > > wrote: > > > > > We're running into a problem with the change made for this issue: > > > http://issues.apache.org/jira/browse/WICKET-1370 > > > > > > Basically, if you have a situation like this where the Login page > > > extends DefaultPage and uses <wicket:extend>: > > > > > > Login.html > > > DefaultPage.html > > > DefaultPage_style1.html > > > DefaultPage_style2.html > > > > > > The markup for DefaultPage will always be based on the first style the > > > site is hit with. This is because the location string ("Login.html") > hasn't > > > changed with the style change. > > > > > > Can anyone think of a simple way to work around this or a simple patch > > > we can apply for now? > > > > > > I've entered this issue for this as well: > > > https://issues.apache.org/jira/browse/WICKET-1507 > > > > > > Thanks, > > > Meetesh > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
