Zhong ZHENG wrote:
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.
Ya, we don't want to code ourselves into a whole of being stuck on a
single container.
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...
Yes, something like this is possible. What about implementing
deployment within the portal and providing a mechanism (perhaps ws?) for
connecting to the portal and sending the deploy/undeploy commands. This
would allow us to have multiple interfaces to the functionality - a
portlet, a command line utility, etc. . .
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?
Either one of those is fine with me. My point is simply that we don't
need to develop our own framework. To me, the choices are:
1) Simple Command Patter Portlet
2) Reuse an existing framework.
I look forward to working with you on the admin. Regards.
ZHENG Zhong
2005/9/5, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<[EMAIL PROTECTED] <mailto:[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] <mailto:[EMAIL PROTECTED]>>*
09/03/2005 01:12 PM
Please respond to
pluto-dev@portals.apache.org <mailto:pluto-dev@portals.apache.org>
To
pluto-dev mailing list <pluto-dev@portals.apache.org
<mailto:pluto-dev@portals.apache.org>>
cc
Subject
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_ <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
