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
Hi Erik,
you might want to use IndexedPageParams, so you could do:
mount(/myPath, myForwardClass.class); in init;
the parameter with index 0 is the first one, the index 1 is second and
so on, delimiteds are the ones by /
eg:
myapp.com/myPath/param0/param1/param2 ... and so on;
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
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,
or the app server which ever it is..
but where are the located?
On Tue, Mar 25, 2008 at 11:19 AM, lars vonk [EMAIL PROTECTED] 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,
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
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
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
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
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
the whole resource thing is soo 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,
just need to add a lastmodifiedtime() to it and we are done :) and it
also gets rid of the
On Tue, Mar 25, 2008 at 6:46 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
the whole resource thing is soo 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
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
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 [EMAIL PROTECTED]
wrote:
well, im saying get rid of Resource/ResourceStream entirely. we dont
need
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
15 matches
Mail list logo
