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
