what code are you thinking of, johan? i don't think this is possible at
all.
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
