On Tue, Mar 25, 2008 at 6:46 PM, Igor Vaynberg <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]
> >
> >
> >
> > 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 <
> [EMAIL PROTECTED]>
> > > 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 <
> [EMAIL PROTECTED]
> > > >
> > > > wrote:
> > > >
> > > >
> > > >
> > > > > and inside the resource you do
> > > > >
> > > > > RequestCycle.get().getRequest().getParameter("foo");
> > > > >
> > > > > -igor
> > > > >
> > > > >
> > > > > On Tue, Mar 25, 2008 at 6:41 AM, Johan Compagner <
> > > [EMAIL PROTECTED]>
> > > > > 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 <
> > > [EMAIL PROTECTED]>
> > > > > >
> > > > > >
> > > > > > 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 <
> > > > > [EMAIL PROTECTED]>
> > > > > > > > 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:
> [EMAIL PROTECTED]
> > > > > > > >> For additional commands, e-mail:
> [EMAIL PROTECTED]
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > > > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
