couldn't the setParameters() method be private or at least package
private? it's really an implementation detail we wouldn't want users
to work with, correct?
On Sat, 6 Aug 2005, Johan Compagner wrote:
> That looks fine to me.
> The only problem is that i was trying to hide the fact that
> RequestCycle.get() CAN return NULL for resources..
> (It can be null when the call is going through getLastModified() of
> wicketservlet....)
> We should come up with something else for that, because the parameters
> are still there.
>
> But with resource having a getParameters.. i think we can add a
> setParameters()
> and call that one in the WicketServlet.getLastModified() That would work
> perfectly because the we also have parameters
> when the last modified call is done (and that has to be done because
> else such a resource can never be cachable....)
>
> johan
>
>
> Jonathan Locke wrote:
> >
> > maybe even add
> >
> > public class Resource
> > {
> > protected ValueMap Resource.getParameters()
> > {
> > return new
> > ValueMap(RequestCycle.get().getRequest().getParameterMap());
> > }
> > }
> >
> > that would allow easy access to typed parameters
> >
> > Jonathan Locke wrote:
> >
> >>
> >> ooooh. very sneaky!
> >> i like it. but maybe we can provide a little helper subclass so
> >> people don't have to
> >> do this to get resource parameters:
> >>
> >> Map params = RequestCycle.get().getRequest().getParameterMap();
> >>
> >> that takes a bit more knowledge of wicket than most people probably
> >> have.
> >>
> >> Johan Compagner wrote:
> >>
> >>> Works fine.
> >>> Just register at startup in youre application a ResourceReference
> >>> (that is youre service)
> >>> (you need head for this because there where 2 bugs in wicket,
> >>> lastModified couldn't return null
> >>> and cachable check didn't go through the isCachable() method but
> >>> cachable variable instead)
> >>>
> >>>
> >>> this is a quick hack of some code
> >>>
> >>> getSharedResources().add("mydynamicresource",new Resource()
> >>> {
> >>> IResourceStream resourceStream = new IResourceStream()
> >>> {
> >>> public Time lastModifiedTime()
> >>> {
> >>> loadResource();
> >>> return null;
> >>> }
> >>> public void close() throws IOException
> >>> {
> >>> is.close();
> >>> is = null;
> >>> }
> >>> public InputStream getInputStream() throws
> >>> ResourceStreamNotFoundException
> >>> {
> >>> loadResource();
> >>> return is;
> >>> }
> >>> public long length()
> >>> {
> >>> loadResource();
> >>> if(is != null)
> >>> {
> >>> try
> >>> {
> >>> return (long)is.available();
> >>> }
> >>> catch (IOException e)
> >>> {
> >>> e.printStackTrace();
> >>> }
> >>> }
> >>> return 0;
> >>> }
> >>> public String getContentType()
> >>> {
> >>> loadResource();
> >>> return "image/gif";
> >>> } };
> >>>
> >>> InputStream is;
> >>> private void loadResource()
> >>> {
> >>> if(is == null && RequestCycle.get() != null)
> >>> {
> >>> Map params =
> >>> RequestCycle.get().getRequest().getParameterMap();
> >>> String fileName = (String)params.get("file");
> >>> if(fileName != null)
> >>> {
> >>> try
> >>> {
> >>> is = new FileInputStream("c:/" + fileName);
> >>> }
> >>> catch (FileNotFoundException e)
> >>> {
> >>> throw new WicketRuntimeException(e);
> >>> }
> >>> }
> >>> else
> >>> {
> >>> is = null;
> >>> }
> >>> }
> >>> }
> >>> public boolean isCacheable()
> >>> {
> >>> return false;
> >>> }
> >>> public IResourceStream getResourceStream()
> >>> {
> >>> return resourceStream;
> >>> }
> >>> });
> >>>
> >>>
> >>> Jonathan Locke wrote:
> >>>
> >>>>
> >>>> right. except one crucial difference. this kind of resource does
> >>>> not need to be
> >>>> registered with the application (and you don't need an image
> >>>> reference to it). i don't think you can do what you suggested
> >>>> below. there are no parameters
> >>>> to image resources currently (unless someone changed something on
> >>>> me... ;-))
> >>>>
> >>>> Johan Compagner wrote:
> >>>>
> >>>>> but what you are describing is pretty much how a resource works now
> >>>>> With one exception you don't have this:
> >>>>>
> >>>>> http://<host>/app/customResources/photos/test/100
> >>>>>
> >>>>> but this
> >>>>>
> >>>>> http://<host>/app/resources/photos?image=test&width=100
> >>>>>
> >>>>> johan
> >>>>>
> >>>>>
> >>>>> Jonathan Locke wrote:
> >>>>>
> >>>>>>
> >>>>>> right.
> >>>>>> but how is this different from the simpler
> >>>>>> WebRequestCycle.onCustomResource?
> >>>>>>
> >>>>>> is it just that it's a little more modular? if that's the goal,
> >>>>>> maybe we should have a generalized
> >>>>>> custom resource architecture (i loathe the word 'service' here
> >>>>>> because it's so unbelievably lacking
> >>>>>> in meaning, btw). we could have just one way of parsing the base
> >>>>>> part of the url and then pass
> >>>>>> the tail on to a resource handler class registered with
> >>>>>> WebRequestCycle. i really hate the idea
> >>>>>> of loading more and more stuff into WebRequest/WebResponse,
> >>>>>> because they are so inconvenient
> >>>>>> to customize. so maybe it's like:
> >>>>>>
> >>>>>> webRequestCycle.add("photos", new CustomResource() { })
> >>>>>>
> >>>>>> and then URLs like:
> >>>>>>
> >>>>>> http://<host>/app/customResources/photos/...
> >>>>>>
> >>>>>> would go to the instance of CustomResource installed on the
> >>>>>> WebRequestCycle...
> >>>>>>
> >>>>>> yeah, i like that a bunch better... is this kindof what you're
> >>>>>> driving at?
> >>>>>>
> >>>>>> Igor Vaynberg wrote:
> >>>>>>
> >>>>>>> Not exactly.
> >>>>>>>
> >>>>>>> I think you are taking a more resource based approach then what
> >>>>>>> I tried to
> >>>>>>> describe. Basically lets say in your case you need to return
> >>>>>>> some resources
> >>>>>>> from within your wicket app that don't fit well with the default
> >>>>>>> request/response processing. What you can do is create your own
> >>>>>>> implementation of WebRequest and WebResponse and register them
> >>>>>>> with wicket
> >>>>>>> under a service name. So when the user hits a url with that
> >>>>>>> service name
> >>>>>>> your registered implementations of WebRequest and WebResponse
> >>>>>>> will be used
> >>>>>>> to process the url and generate the response as opposed to
> >>>>>>> wicket's default.
> >>>>>>> You can completely bypass wicket's pages/components and just
> >>>>>>> write your file
> >>>>>>> into the response.
> >>>>>>>
> >>>>>>> So its not just a resource reference but more like a sub-servlet
> >>>>>>> that works
> >>>>>>> inside wicket and handles all urls with a specific service
> >>>>>>> attrubute.
> >>>>>>>
> >>>>>>> The advantage to a separate servlet is that you still get all
> >>>>>>> the wicket
> >>>>>>> features because your alternate impls are still running within
> >>>>>>> wicket.
> >>>>>>>
> >>>>>>> You can write an image service that given an image name from
> >>>>>>> within a
> >>>>>>> package will write it to the response, kind of like a resource
> >>>>>>> reference
> >>>>>>> does now.
> >>>>>>>
> >>>>>>> Does this make sense or do I just now know enough about resource
> >>>>>>> references
> >>>>>>> in wicket?
> >>>>>>>
> >>>>>>>
> >>>>>>> -Igor
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: [EMAIL PROTECTED]
> >>>>>>>> [mailto:[EMAIL PROTECTED] On Behalf Of
> >>>>>>>> Johan Compagner
> >>>>>>>> Sent: Friday, August 05, 2005 2:14 PM
> >>>>>>>> To: wicket-user@lists.sourceforge.net
> >>>>>>>> Subject: Re: [Wicket-user] Re: Problem
> >>>>>>>>
> >>>>>>>> but isn't this adding a esourcereference to youre application?
> >>>>>>>> Then that resourcereference will becalled under the url:
> >>>>>>>>
> >>>>>>>> /wicket-examples/images/resources/home/image5
> >>>>>>>>
> >>>>>>>> and you can do anything you want in the resource that reference
> >>>>>>>> is making.
> >>>>>>>>
> >>>>>>>> johan
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Igor Vaynberg wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Or someone might write components/pages that generate xml
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> and are xslt
> >>>>>>>>
> >>>>>>>>> transformed into a ui. Or voice xml components. And im sure
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> there are
> >>>>>>>>
> >>>>>>>>> a thousand more reasons.
> >>>>>>>>>
> >>>>>>>>> Tapestry takes an nice approach that allows easy
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> integration of things
> >>>>>>>>
> >>>>>>>>> like this. You can basically write your own service
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> providers (in this
> >>>>>>>>
> >>>>>>>>> case customized webrequest/webresponse pair) and register them
> >>>>>>>>> with the framework. When your url contains a
> >>>>>>>>> service=<service-name> tapestry uses your service to process
> >>>>>>>>> the request and
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> produce the response.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> -Igor
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: [EMAIL PROTECTED]
> >>>>>>>>>> [mailto:[EMAIL PROTECTED] On Behalf
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> Of Philip
> >>>>>>>>
> >>>>>>>>>> A. Chapman
> >>>>>>>>>> Sent: Friday, August 05, 2005 1:03 PM
> >>>>>>>>>> To: wicket-user@lists.sourceforge.net
> >>>>>>>>>> Subject: Re: [Wicket-user] Re: Problem
> >>>>>>>>>>
> >>>>>>>>>> Gili wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Jon, I think you need to give more information about
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> your actual
> >>>>>>>>>>
> >>>>>>>>>>> requirements. As I already mentioned, I have a simple
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> servlet which
> >>>>>>>>
> >>>>>>>>>>> serves up images by ID and the ID is passed in via a HTTP
> >>>>>>>>>>> POST (although originally I had it going via a HTTP GET and you
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> could do this too).
> >>>>>>>>>>
> >>>>>>>>>>> I don't see why one would need access to the Wicket
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> session...?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>> Again, it isn't clear to me what your actual requirements
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> are. If you
> >>>>>>>>>>
> >>>>>>>>>>> simply have a client-server architecture, why not code
> >>>>>>>>>>> up
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>> all your
> >>>>>>>>
> >>>>>>>>>>> server components as servlets to send image data, etc?
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> This is not Jon's argument, I do not believe, but an
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> argument that I
> >>>>>>>>
> >>>>>>>>>> think is valid. Let us say that your images served up by
> >>>>>>>>>> your servlet are generated charts, such as the relative wages
> >>>>>>>>>> of employees. You wouldn't want just anyone to be able to
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> access this
> >>>>>>>>
> >>>>>>>>>> data unless they had authenticated successfully. In order to
> >>>>>>>>>> determine whether they have authenticated, you would need to
> >>>>>>>>>> check the wicket session.
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Philip A. Chapman
> >>>>>>>>>>
> >>>>>>>>>> Application Development:
> >>>>>>>>>> Java, Visual Basic (MCP), PostgreSQL, MySQL, MSSQL Linux,
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> Windows 9x,
> >>>>>>>>
> >>>>>>>>>> Windows NT, Windows 2000, Windows XP
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> -------------------------------------------------------
> >>>>>>>>> SF.Net email is Sponsored by the Better Software Conference &
> >>>>>>>>> EXPO September 19-22, 2005 * San Francisco, CA * Development
> >>>>>>>>> Lifecycle Practices Agile & Plan-Driven Development *
> >>>>>>>>> Managing
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Projects & Teams
> >>>>>>>>
> >>>>>>>>> * Testing & QA Security * Process Improvement & Measurement *
> >>>>>>>>> http://www.sqe.com/bsce5sf
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Wicket-user mailing list
> >>>>>>>>> Wicket-user@lists.sourceforge.net
> >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/wicket-user
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> -------------------------------------------------------
> >>>>>>>> SF.Net email is Sponsored by the Better Software Conference &
> >>>>>>>> EXPO September 19-22, 2005 * San Francisco, CA * Development
> >>>>>>>> Lifecycle Practices Agile & Plan-Driven Development * Managing
> >>>>>>>> Projects & Teams * Testing & QA Security * Process Improvement
> >>>>>>>> & Measurement * http://www.sqe.com/bsce5sf
> >>>>>>>> _______________________________________________
> >>>>>>>> Wicket-user mailing list
> >>>>>>>> Wicket-user@lists.sourceforge.net
> >>>>>>>> https://lists.sourceforge.net/lists/listinfo/wicket-user
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> -------------------------------------------------------
> >>>>>>> SF.Net email is Sponsored by the Better Software Conference & EXPO
> >>>>>>> September 19-22, 2005 * San Francisco, CA * Development
> >>>>>>> Lifecycle Practices
> >>>>>>> Agile & Plan-Driven Development * Managing Projects & Teams *
> >>>>>>> Testing & QA
> >>>>>>> Security * Process Improvement & Measurement *
> >>>>>>> http://www.sqe.com/bsce5sf
> >>>>>>> _______________________________________________
> >>>>>>> Wicket-user mailing list
> >>>>>>> Wicket-user@lists.sourceforge.net
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/wicket-user
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> -------------------------------------------------------
> >>>>>> SF.Net email is Sponsored by the Better Software Conference & EXPO
> >>>>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> >>>>>> Practices
> >>>>>> Agile & Plan-Driven Development * Managing Projects & Teams *
> >>>>>> Testing & QA
> >>>>>> Security * Process Improvement & Measurement *
> >>>>>> http://www.sqe.com/bsce5sf
> >>>>>> _______________________________________________
> >>>>>> Wicket-user mailing list
> >>>>>> Wicket-user@lists.sourceforge.net
> >>>>>> https://lists.sourceforge.net/lists/listinfo/wicket-user
> >>>>>>
> >>>>>
> >>>>>
> >>>>> -------------------------------------------------------
> >>>>> SF.Net email is Sponsored by the Better Software Conference & EXPO
> >>>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> >>>>> Practices
> >>>>> Agile & Plan-Driven Development * Managing Projects & Teams *
> >>>>> Testing & QA
> >>>>> Security * Process Improvement & Measurement *
> >>>>> http://www.sqe.com/bsce5sf
> >>>>> _______________________________________________
> >>>>> Wicket-user mailing list
> >>>>> Wicket-user@lists.sourceforge.net
> >>>>> https://lists.sourceforge.net/lists/listinfo/wicket-user
> >>>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------
> >>>> SF.Net email is Sponsored by the Better Software Conference & EXPO
> >>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> >>>> Practices
> >>>> Agile & Plan-Driven Development * Managing Projects & Teams *
> >>>> Testing & QA
> >>>> Security * Process Improvement & Measurement *
> >>>> http://www.sqe.com/bsce5sf
> >>>> _______________________________________________
> >>>> Wicket-user mailing list
> >>>> Wicket-user@lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/wicket-user
> >>>>
> >>>
> >>>
> >>> -------------------------------------------------------
> >>> SF.Net email is Sponsored by the Better Software Conference & EXPO
> >>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> >>> Practices
> >>> Agile & Plan-Driven Development * Managing Projects & Teams *
> >>> Testing & QA
> >>> Security * Process Improvement & Measurement *
> >>> http://www.sqe.com/bsce5sf
> >>> _______________________________________________
> >>> Wicket-user mailing list
> >>> Wicket-user@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/wicket-user
> >>>
> >>
> >>
> >> -------------------------------------------------------
> >> SF.Net email is Sponsored by the Better Software Conference & EXPO
> >> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> >> Practices
> >> Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> >> & QA
> >> Security * Process Improvement & Measurement *
> >> http://www.sqe.com/bsce5sf
> >> _______________________________________________
> >> Wicket-user mailing list
> >> Wicket-user@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/wicket-user
> >>
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> > & QA
> > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Wicket-user mailing list
> > Wicket-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
