For now I can't benefit from 304 Not Modified when shared parameterized resource is mounted with custom mount path (say /databaseimage/ in contrary to /resources/) and backed by database. I mean it is not easy to benefit from just implementing IResourceStream.lastModifiedTime(). It is due WicketFilter checks only /resource for not modification. The same about stateless pages (that for instance hosts the db images, which "not modification" status depends completely on image timestamp).
I believe Igor is right about IResourceStream. Page and Shared Resource both are resources. And handling them polimorfly would simplify things. I look forward for the new URL handling technology. I hope it will happen within 1.5. igor.vaynberg wrote: > > well, these are all the questions we would have to answer when we are > looking into this in detail. i dont have the answers right now, im > just stating what i would like to see happen. i think the entire > resource api has become very very bloated and can be simplified. > > -igor > > > On Tue, Mar 25, 2008 at 12:43 PM, Johan Compagner <jcompag...@gmail.com> > wrote: >> kill IResourceStream looks doable >> But also resource? >> >> Where does a ResourceReference then point to? >> How do we name the byte[] or streams? >> >> johan >> >> >> On Tue, Mar 25, 2008 at 7:45 PM, Igor Vaynberg <igor.vaynb...@gmail.com> >> >> >> wrote: >> >> > well, im saying get rid of Resource/ResourceStream entirely. we dont >> > need that abstraction, we can just add whatever is missing to resource >> > target. actually that way you can also implement page caching >> > easily...maybe... >> > >> > anyways, irequesttarget.getlastmodified(pageparameters) can alleviate >> > reliance on the request cycle >> > >> > -igor >> > >> > >> > On Tue, Mar 25, 2008 at 11:38 AM, Johan Compagner >> <jcompag...@gmail.com> >> > wrote: >> > > On Tue, Mar 25, 2008 at 6:46 PM, Igor Vaynberg >> <igor.vaynb...@gmail.com> >> > > wrote: >> > > >> > > >> > > > the whole resource thing is soooooo bloated. something we should >> > > > simplify in 1.5. im all for getting rid of it entirely. we >> already >> > > > have a nice interface for streams and that is called >> IRequestTarget, >> > > >> > > >> > > we already have that: >> > > >> > > SharedResourceRequestTarget -> ResourceStreamRequestTarget >> > > >> > > >> > > >> > > >> > > >> > > > >> > > > just need to add a lastmodifiedtime() to it and we are done :) >> and it >> > > > also gets rid of the inputstream<->outputstream inconsistency. >> why >> > > > should a resource provide an inputstream and us copy it when the >> > > > resource can just dump it into the response directly... >> > > >> > > >> > > we already have that +/- also: IResourceStreamWriter >> > > >> > > But i agree it can be simpler >> > > >> > > But HEAD request should not go into the complete wicket cycle >> > > Those should be fast as possible. because head request are i think >> the >> > > happening the most of all the request. >> > > >> > > johan >> > > >> > > >> > > >> > > >> > > >> > > > >> > > > >> > > > -igor >> > > > >> > > > >> > > > On Tue, Mar 25, 2008 at 10:33 AM, Johan Compagner < >> > jcompag...@gmail.com> >> > > > wrote: >> > > > > no but the params could contain a filename >> > > > > and against that you check the last modified time stamp also >> in >> > the DB >> > > > > >> > > > > just also for performance, if we call: >> > > > > public abstract IResourceStream getResourceStream(); >> > > > > >> > > > > then dont already get all the data. >> > > > > Because that call can also just be used for lastModified() >> check. >> > > > > >> > > > > that should only lazy be done with the >> > IResourceStream.getInputStream() >> > > > call >> > > > > >> > > > > johan >> > > > > >> > > > > >> > > > > On Tue, Mar 25, 2008 at 5:51 PM, Igor Vaynberg < >> > igor.vaynb...@gmail.com >> > > > > >> > > > > >> > > > > >> > > > > wrote: >> > > > > >> > > > > > well, hopefully you dont instantiate the resource stream if >> its >> > just >> > > > a >> > > > > > HEAD response... >> > > > > > >> > > > > > -igor >> > > > > > >> > > > > > >> > > > > > On Tue, Mar 25, 2008 at 9:47 AM, Johan Compagner < >> > > > jcompag...@gmail.com> >> > > > > > wrote: >> > > > > > > no do >> > > > > > > >> > > > > > > resource/this.getParameters() >> > > > > > > >> > > > > > > dont try to get the RequestCylce >> > > > > > > if it is a HEAD request (last modified check) it doesn't >> have >> > to >> > > > be >> > > > > > there.. >> > > > > > > >> > > > > > > johan >> > > > > > > >> > > > > > > On Tue, Mar 25, 2008 at 5:44 PM, Igor Vaynberg < >> > > > igor.vaynb...@gmail.com >> > > > > > > >> > > > > > > wrote: >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > and inside the resource you do >> > > > > > > > >> > > > > > > > RequestCycle.get().getRequest().getParameter("foo"); >> > > > > > > > >> > > > > > > > -igor >> > > > > > > > >> > > > > > > > >> > > > > > > > On Tue, Mar 25, 2008 at 6:41 AM, Johan Compagner < >> > > > > > jcompag...@gmail.com> >> > > > > > > > wrote: >> > > > > > > > > ok just make such a class >> > > > > > > > > make a (Dynamic)Resource >> > > > > > > > > that you add to the shared resources >> > > > > > > > > >> > > > > > > > > That resource looks in the params to figure out what >> to >> > serve >> > > > > > > > > >> > > > > > > > > with RequestCycle.urlFor(final ResourceReference >> > > > > > resourceReference, >> > > > > > > > ValueMap >> > > > > > > > > parameters) you can create urls with those params. >> > > > > > > > > >> > > > > > > > > called for example by ResourceLink or Image >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > johan >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > On Tue, Mar 25, 2008 at 2:07 PM, Erik van Oosten < >> > > > > > e.vanoos...@grons.nl> >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > wrote: >> > > > > > > > > >> > > > > > > > > > Hi Lars, >> > > > > > > > > > >> > > > > > > > > > They are not that static :) >> > > > > > > > > > >> > > > > > > > > > We import and export the images from a database we >> > manage. >> > > > By >> > > > > > > > 'static' I >> > > > > > > > > > meant that the images do not change over time, so >> I >> > want >> > > > fixed >> > > > > > URLs >> > > > > > > > for >> > > > > > > > > > them. >> > > > > > > > > > >> > > > > > > > > > Sorry for the confusion. >> > > > > > > > > > >> > > > > > > > > > Regards, >> > > > > > > > > > Erik. >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > lars vonk wrote: >> > > > > > > > > > > You could put Apache in front and let it serve >> you >> > static >> > > > > > images? >> > > > > > > > > > > >> > > > > > > > > > > Lars >> > > > > > > > > > > >> > > > > > > > > > > On Tue, Mar 25, 2008 at 10:18 AM, Erik van >> Oosten < >> > > > > > > > e.vanoos...@grons.nl> >> > > > > > > > > > > wrote: >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> Hi, >> > > > > > > > > > >> >> > > > > > > > > > >> I am looking for a way to serve many static >> images. >> > It >> > > > is >> > > > > > > > important >> > > > > > > > > > that >> > > > > > > > > > >> I do not have to separately register them (as >> with >> > > > > > > > SharedResources, as >> > > > > > > > > > I >> > > > > > > > > > >> understood) as there about 20.000 to 50.000 of >> > them, and >> > > > the >> > > > > > set >> > > > > > > > > > changes >> > > > > > > > > > >> continuously. >> > > > > > > > > > >> >> > > > > > > > > > >> The most obvious thing that comes to mind is a >> > static >> > > > > > resource >> > > > > > > > that >> > > > > > > > > > >> takes parameters that are extracted from the >> URL >> > > > (similar to >> > > > > > > > Page). But >> > > > > > > > > > >> I could not find such a thing. >> > > > > > > > > > >> >> > > > > > > > > > >> I am now considering implementing a servlet, >> but >> > I'd >> > > > rather >> > > > > > stay >> > > > > > > > within >> > > > > > > > > > >> the framework. >> > > > > > > > > > >> >> > > > > > > > > > >> Regards, >> > > > > > > > > > >> Erik. >> > > > > > > > > > >> >> > > > > > > > > > >> -- >> > > > > > > > > > >> Erik van Oosten >> > > > > > > > > > >> http://day-to-day-stuff.blogspot.com/ >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > >> > > > >> --------------------------------------------------------------------- >> > > > > > > > > > >> To unsubscribe, e-mail: >> > > > users-unsubscr...@wicket.apache.org >> > > > > > > > > > >> For additional commands, e-mail: >> > > > users-h...@wicket.apache.org >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > > >> >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > >> > --------------------------------------------------------------------- >> > > > > > > > > > To unsubscribe, e-mail: >> > users-unsubscr...@wicket.apache.org >> > > > > > > > > > For additional commands, e-mail: >> > > > users-h...@wicket.apache.org >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > >> --------------------------------------------------------------------- >> > > > > > > > To unsubscribe, e-mail: >> users-unsubscr...@wicket.apache.org >> > > > > > > > For additional commands, e-mail: >> > users-h...@wicket.apache.org >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > --------------------------------------------------------------------- >> > > > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> > > > > > For additional commands, e-mail: >> users-h...@wicket.apache.org >> > > > > > >> > > > > > >> > > > > >> > > > >> > > > >> --------------------------------------------------------------------- >> > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> > > > For additional commands, e-mail: users-h...@wicket.apache.org >> > > > >> > > > >> > > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> > For additional commands, e-mail: users-h...@wicket.apache.org >> > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > -- View this message in context: http://old.nabble.com/Shared-resources-with-parameters--tp16272101p27717799.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org