> As you already can tell from my changes, this will require some big > structural changes because currently Wicket is still very deeply > entangled with the Servlet api. > > To be able to use Wicket in a Portlet context, *all* of that needs to > be abstracted away to a generalized interface. And, although I will do > my best to keep as much of the current public api intact, important > changes will be required.
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). I need to get access to it for two reasons: 1) To manually set and get cookies (e.g., getWebResponse().getHttpServletResponse().addCookie(cookie); ) 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... [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!] 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 Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
