But....the framework does not run well....because of a bug of portlet session binding in the container. I posted a mail to the mailing list yesterday to report the bug. Last sunday I spent a whole afternoon trying to figure that out....but failed.
2005/9/5, Zhong ZHENG <[EMAIL PROTECTED]>:
Hi,
I am thinking of separating the pluto admin app into a single subproject, like the testsuite, as mentioned earlier. For the requirements, there will be no problem for the file upload and war deployment functionalities, because they are independent to the portal driver. But the ability to update the portal's configuration object seems a little bothering to me.
The portal configuration is an object private to the portal webapp. Currently it is saved in the portal's servlet context as an attribute. So how should the portal expose the operation on the config to the admin app?
One way is to separate the portal config API into a single jar file (like the descriptors) and put it into tomcat's shared/lib directory, to make it shared by all the webapps. But that may have some serious problems:
1) That gives all the webapps the ability to operate the portal's configuration object. In fact, only the admin app should have that ability, but we cannot prevent other webapps from doing that, if some of them really want to do something bad.
2) Even for the admin app, it needs to use tomcat's cross context functionality to retrieve the current configuration object from the portal's servlet context. That depends heavily on the servlet container's implementation. We have already had an issue about that.
Now I am thinking if we may have an alternate way to perform the deployment. Maybe we may ask the portal driver to detect automatically the deployed portlet apps, something like how tomcat does to deploy webapps. I am not sure if that is feasible...
For the design pattern: if we use the command pattern, we do not need to use a portlet framework any more (such as portals-bridges/struts or tapestry-portlets). So, what is your preference? To implement the admin all by ourselves, or to use an existing framework that supports portlets?
I look forward to working with you on the admin. Regards.
ZHENG Zhong
2005/9/5, [EMAIL PROTECTED] < [EMAIL PROTECTED]>:
Hi Zheng,
I'd like to collaborate on the Admin portlets for Pluto 1.1 too. I like the command pattern that you used in your first try at admin portlets for Pluto 1.1. The only change I'd like is too add role-based security by checking security-role-ref in portlet.xml and doing a PortletRequest.isUserInRole() check before control is passed to the action.
Here are my minimum requirements for admin portlets:
1. File upload and war deployment into webapps directory.
a. Modify web.xml and Pluto configuration files as necessary
2. Ability to undeploy portlets by removing configurations and deleting deployments.
3. Ability to configure and change layout of a portlet application.
We should also plan for the administration of authenticated users and user information attributes (PLT.17) in the admin console.
/Craig
Zhong ZHENG <[EMAIL PROTECTED]> 09/03/2005 01:12 PM
pluto-dev@portals.apache.org
pluto-dev mailing list <pluto-dev@portals.apache.org>
refactoration of Pluto Admin 1.1
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:
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.
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'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
--
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
