-----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]
