Dan Gould wrote:
Ate-- Welcome to the project and glad to see that you're adding portlet support; it should be very nice. I'm a very happy user... I haven't had a chance to look at your code, but I did want to veryify that you're not going to so anything that will prevent us from getting at the HttpServletRequesst/HttpServletResponse (I'm ok if we need an extra call or two).
First of all, be assured: it is my first priority to *not* harm any of the current features when using Wicket within a Servlet environment (only).
I need to get access to it for two reasons: 1) To manually set and get cookies (e.g., getWebResponse().getHttpServletResponse().addCookie(cookie); )
As said: this will remain supported when used from a Servlet. But, for a Portlet environment this is a different matter! Adding Cookies is currently explicitly *not* supported in the JSR-168. I won't go into the reason and details behind it here, but this is just one example of the many difficulties we face in providing proper JSR-168 support. Note: I do intend to provide Cookies support, even in Portlets! But it will require a supporting Portal and Portlet engine, like Jetspeed-2,
and 2) To find the full URL that we were called with, since I use different templates depending on which domain my site was accessed through (if the user came to http://www.foo.com/ they'll see something different than if they hit http://www.bar.com/ even though they're running the same code). Wicket doesn't seem to provide any way to access this directly...
You should be able to retrieve that easily from the HttpServletRequest. Anyway, same story as above. Portlets don't have a concept of a "full" URL invoking them... Which one would it have to be if more than one portlet is displayed on a page? But also again: I'm going to provide a solution for that as well.
[BTW: Is the portlet support two-way: portlets can be treated as wicket components? So, I could have a <span wicket:id="portlet"> and then run an arbitary portlet in that span? That would be great!]
It certainly would be great but its way out of scope for my current actions. What you're asking for is providing JSR-168 container support *within* wicket. It is doable though... We provide JSR-168 support in Jetspeed-1 by embedding Jetspeed-2 as portlet container inside Jetspeed-1 (this is our Jetspeed-1 1.6 "Fusion" release). But for now, I'll settle for just "plain" JSR-168 support in Wicket, thank you ;-)
Thanks & best, Dan ------------------------------------------------------- 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/wicket-user
