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

Reply via email to