Hi Zheng,
Whether to have the admin portlet app as a separate webapp or incorporated into the Pluto's portal is a thorny issue. I originally created the admin portlet app as a separate webapp, but incorporating it into the portal made reuse a lot easier without having to open up the container to the 'public' (as you mentioned in problem 1). I am undecided as which way to go in Pluto 1.1.
All of my focus has been on Pluto 1.0.1, so I can't advise you right now on how to implement configuration by admin portlets in Pluto 1.1. Automatic deployment by the container sounds interesting, but I don't think it is a good idea because reconfiguration (e.g. changing portlet app layout) will require direct involvement of the admin portlets. It will be best to keep all admin functions under the control of the admin portlet app.
As I said in a previous post today, I think it is a bad idea to use a 'portletized' web framework. All of the portlet implementations are still under development, and I think we need to keep external dependancies down to a minimum. Struts is a particular bad choice, IMHO, because Struts is in maintenance mode and appears to be a passe web framework to be superceded by JSF. However, we don't need to invent a portlet framework. The portlet API is simple enough for us to use out-of-the box with a common entry point (master controller in J2EE pattern-speak).
Here are a few other requirements for the admin portlet app I've thought about:
1. Separate portlets for deployment (file upload and config file inserts) and layout.
2. Architectural flexibility that will allow different implementation of admin functions in different servlet containers (especially jetty).
FYI, I have the day off today and am busy with other things, so my response to the various discussions might be spotty. I will try to start wrapping my head around Pluto 1.1 this week.
/Craig
| Zhong ZHENG <[EMAIL PROTECTED]>
09/05/2005 11:22 AM
|
|
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
|
|
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
http://heavyz.blogspot.com
http://spaces.msn.com/members/zhengzhong
