Zhong ZHENG wrote:
Hi David,
I will check the struts adapter in the portals-bridges project.
ok.
Also, check this out:
http://jakarta.apache.org/tapestry/tapestry-portlet/
I will try to re-explain the second point. To deploy a portlet
application, we need to rewrite the war file by adding servlets and
mappings for each portlet, and then update the driver configuration.
That depends on the implementation of the portal driver, which will
change probably in the future. So I would like to provide an interface
to encapsulate those operations, like the following:
public interface DriverOperator {
public void deployPortletApp(...);
public void undeployPortletApp(...);
}
In this way, the admin app may create an operator (by using a
DriverOperatorFactory, for example) and leverage the deploying and
undeploying tasks to it without knowing how the portlet app is deployed
or undeployed.
Then provide a DriverOperator implementation class. If in the future,
the pluto portal driver is updated, that implementation class is the
only place that needs to be updated accordingly, and we don't need to
modify the admin app any more.
Sounds good to me. So, I guess what you're thinking is that you'll
abstract this stuff out into a seperate portlet-app - kindof like the
testsuite. The issue that we had before is that there were some classes
in the portal webapp which were useful for the portlet - however, now
that we've abstracted the descriptor service out, we may not have that
issue. I agree 100% that the admin portlet SHOULD be seperate from the
portal. If we do find dependencies only available to the portal webapp,
we should properly take care of those issues.
Oh! Also. . .regarding:
> > I'd like to collaborate with you on the admin app.
The best way to do that will be to make the source code easily available
ASAP. This is probably best done by submitting it for commit ealy on.
Once in svn, other people have a much easier time collaborating. Don't
worry about making things perfect and working before contributing the
patch for this - feel free to contribute the basics and allow things to
develop. . .
David
Regards.
ZHENG Zhong
2005/9/5, David H. DeWolf <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>:
Zhong ZHENG wrote:
> Hi there,
>
> Since you have made some modifications on the Pluto Driver
subproject,
> the previous Pluto Admin did not work any more. So I am thinking of
> refactoring the admin app:
what are the specific mods you're talking about? the refactoring of the
config into configurable services?
>
> 1. Provide a pluto-independent Struts-like MVC framework for
portlet. I
> don't know whether Struts supports portlet currently, but I think
it not
> necessary to require Struts to run the admin. I can write a very
simple
> yet not full-featured MVC framework based on which I may
facilitate the
> admin development.
My STRONG preference is that we do not write our own framework. I
believe that is beyond the scope of our project. Instead, let's
leverage something which allready exists. What about tapestry? I
believe that 4.x has portlet support. If not, take a look at
portals-bridges for a struts adapter.
>
> 2. Separate the pluto portal driver dependent codes into a single
> package. Since Pluto 1.1 is still on development, there will
probably be
> midifications on the portal driver. So separating the dependent code
> will make it easier to meet the future need.
I'm not sure I understand? Can you explain what you mean?
>
> I'd like to collaborate with you on the admin app. So what you think
> about the refactoring plan?
>
> Regards.
>
> --
>
> ZHENG Zhong
> heavyzheng {AT} gmail {D0T} com
> http://heavyz.sourceforge.net
>
--
ZHENG Zhong
1 Avenue Alphand
75116 Paris, France
+33 6 76 80 45 90
heavyzheng {AT} gmail {D0T} com
http://heavyz.sourceforge.net <http://heavyz.sourceforge.net>
http://heavyz.blogspot.com
http://spaces.msn.com/members/zhengzhong
