I will check the struts adapter in the portals-bridges project.
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.
Regards.
ZHENG Zhong
2005/9/5, David H. DeWolf <[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.blogspot.com
http://spaces.msn.com/members/zhengzhong
