> -----Original Message----- > From: John Rousseau [mailto:[EMAIL PROTECTED] > Sent: mardi 10 ao�t 2004 16:07 > To: Cactus Developers List > Subject: Re: Portlet support > > Hi Vincent, > > On Sun, 8 Aug 2004 12:21:40 +0200, Vincent Massol <[EMAIL PROTECTED]> > wrote: > > > Hi John, > > > > I think you're the first one to ask how to use Cactus to unit test > Portlets! > > Ok. There's a lot of interest here in being able to use this, so I'm > hoping that the community can benefit from it too.
cool > > > It should be relatively easy (but a big and long task) to implement > support > > for Portlets inside Cactus and I'm all for integrating it into the > project > > should you or someone provide a patch for it. Actually if someone is > really > > keen to work on this and support it on the long term, I'd even prefer to > > make that person a committer on the project (after he's proved himself > of > > course ;-)) as that person will be the best placed to fix bugs, improve > the > > code, etc. > > > > As a quickstart, here are the Java classes that would need to be > implemented > > in the Cactus framework subproject: > > > > * Create a PortletTestCase class (similar to the ServletTestCase one) > > * Create a PortletConfiguration interface + DefaultPortletConfiguration > > implementation class (again similar to the Servlet one) > > * Create PortletImplicitObjects, PortletTestCaller and > PortletTestController > > classes > > * Create wrappers around Portlet implicit objects *if* need be only > > Great. Thanks! > > I have all of these (roughly) implemented, but it required a lot of > duplicate code. I can't make use of most of the *Web* base classes even > though much of the functionality is the same. Some of the problems are > that many of the methods throw ServletException where I need to throw > something like a PortletException (see the TestCaller implementations). > Once I have this working, we should talk about some refactoring. It might > be nice to have these methods throw something like a Cactus > ContainerException and we could then wrap that in an API-specific > exception in the redirectors. Agreed > > It might make things cleaner if we added another abstract base class layer > above the *Web* ones that had the common functionality to both sides. Agreed > > > That's the easy part but would be enough for users to start benefiting > from > > it. They would need to manunally start their portlet container and > manually > > deploy their Cactus tests into it though. > > Cool. > > > The next step is to add support for Portlets inside the Cactus > integrations > > subprojects, namely: the Ant integration subproject, the Maven > integration > > subproject, create a Portlet Test Runner (similar to the Servlet Test > > Runner), etc. > > Ant integration would be at the top of my list and I probably would not > release anything until I had this. I've yet to use Maven, so this support > would probably come later. Ok, cool > > > But again, this can be implemented bit by bit over time. > > > > If you're interested in implementing this for Cactus, you would also > need to > > follow the Cactus development guidelines > > (http://jakarta.apache.org/cactus/participating/coding_conventions.html, > > http://jakarta.apache.org/cactus/participating/apis.html). > > Yup. Your coding standards are close enough to mine so that it's easy to > stick to the rules. That's nice ;-) > > I've created a separate "portlet" tree, parellel to share, j2ee12 and > j2ee13 since the portlet spec is not part of J2EE yet. Let me know if you > would like me to do otherwise. I think it's fine for now. > > > The only request I'm asking is that if you wish to start this > initiative, > > that you do it seriously and consistently over time. There's nothing as > > detrimental for an open source project as someone who start working on > > something and then stops midway (It happened to us with the Eclipse > plugin > > for Cactus - The guy started and then left the project with something > > halfway working). > > I totally understand. There are a few discussions going on internally > about product focus and as soon as they are resovled I will know if I can > commit to this project. I won't submit any code until I am sure I can > dedicate the time / resources. The QA group in my division will be using > this and I can use them to help support the functionality. Very cool. Thanks > > > Let me know what you think and fire any specific questions you have! > > So far, so good. Not that you have to deal with this, but the two biggest > problems that I am going to face are: > > 1) Portlet invocation is done through a portal. All portals that I am > familiar with provide the ability to render a single portlet, but > everybody does it a bit differently. I'm going to need some flexible URL > invocation code to make this work on multiple portals. ok > 2) Servlets, JSPs and Filters have a single request/response object pair > that they share for invoking the service() method. They then dispatch to > the do*() methods via the HttpServlet. Portlets have two "service"-like > methods, processAction() and render(). These methods take different > request/response objects (although they are both subclasses of a base). > The render() method dispatches to various do*() methods based on portlet > mode. Unlike servlets which have well-defined HTTP methods that they > handle, portlet developers can write custom modes. I hope to hide these > differences in the TestController, but I may need to spider these changes > all the way down to the tests themselves. Ugh! That's ok and from your description it appears as if making these implicit container objects available from the PortletTestCase is the right way to go (Please note that I am still portlet ignorant... I need to do some reading). Thanks John -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
