You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Zhong ZHENG <he...@gmail.com> on 2005/09/03 19:12:23 UTC
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
Re: refactoration of Pluto Admin 1.1
Posted by "David H. DeWolf" <dd...@apache.org>.
CDoremus@hannaford.com wrote:
>
> David,
>
> Most of the most common web frameworks now have portlet adapters
> including Struts, Web Work, Tapestry, Spring, Cocoon and Java Server Faces.
>
> But I'd rather not pick one of these at this time and add unneeded
> complication into the mix. The portlet API is simple enough and
> something we should be able to work with easily. As I said in my
> previous post, we can build on Zheng's command-pattern used in his first
> iteration of Pluto 1.1 admin portlets.
>
I guess it really depends about the scope of what we're talking about.
In Zheng's original post, I got the impression that he was planning to
develop a "framework" but scale it down a little to eliminate the bells
and whistles. I (perhaps mistakenly) assumed that meant a framework
which could be reused on other portlet applications -- I don't want to
have to suppport that within pluto and if we really need one would much
rather just pick one of the available ones allready. If on the other
hand we're just talking about implementing a simple controller portlet -
that's a different story.
> If we are going to pick a framework it should be JSF since it is a Java
> Standard (JSR) like the Portlet API.
:), I'm not a huge fan of JSF. Of course, I would be open to discussing
it if we really need it. . .
David
> /Craig
>
>
>
> *"David H. DeWolf" <dd...@apache.org>*
>
> 09/05/2005 08:34 AM
> Please respond to
> pluto-dev@portals.apache.org
>
>
>
> To
> pluto-dev@portals.apache.org
> cc
>
> Subject
> Re: refactoration of Pluto Admin 1.1
>
>
>
>
>
>
>
>
>
>
> 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 <ddewolf@apache.org
> <ma...@apache.org>>:
> >
> >
> >
> > 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
> >
> >
>
Re: refactoration of Pluto Admin 1.1
Posted by CD...@hannaford.com.
David,
Most of the most common web frameworks now have portlet adapters including
Struts, Web Work, Tapestry, Spring, Cocoon and Java Server Faces.
But I'd rather not pick one of these at this time and add unneeded
complication into the mix. The portlet API is simple enough and something
we should be able to work with easily. As I said in my previous post, we
can build on Zheng's command-pattern used in his first iteration of Pluto
1.1 admin portlets.
If we are going to pick a framework it should be JSF since it is a Java
Standard (JSR) like the Portlet API.
/Craig
"David H. DeWolf" <dd...@apache.org>
09/05/2005 08:34 AM
Please respond to
pluto-dev@portals.apache.org
To
pluto-dev@portals.apache.org
cc
Subject
Re: refactoration of Pluto Admin 1.1
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 <ddewolf@apache.org <mailto:ddewolf@apache.org
>>:
>
>
>
> 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
>
>
Re: refactoration of Pluto Admin 1.1
Posted by "David H. DeWolf" <dd...@apache.org>.
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 <ddewolf@apache.org <ma...@apache.org>>:
>
>
>
> 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
>
>
Re: refactoration of Pluto Admin 1.1
Posted by Zhong ZHENG <he...@gmail.com>.
Hi David,
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 <dd...@apache.org>:
>
>
>
> 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
Re: refactoration of Pluto Admin 1.1
Posted by "David H. DeWolf" <dd...@apache.org>.
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
>
Re: refactoration of Pluto Admin 1.1
Posted by Zhong ZHENG <he...@gmail.com>.
Hi,
I enjoy the discussion with you. Here are some points I summarized from the
conversation:
1. Using the command pattern to implement the admin app is preferred. In
this way we do not need some external dependencies. The patch I submitted to
JIRA contains a framework designed for the admin app. Maybe that is too
complicated and shoud be simplified?
2. As Craig said, whether to have the admin app as a separate webapp or
incorporated into the Pluto's portal is a thorny issue. David proposed to
implement the deployment within the portal and provide a mechanism for
connecting to the portal and sending the deploy/undeploy commands, in order
to allow multiple interfaces to the functionality. I like that idea.
3. The admin app implementation should not be bound to a single servlet
container (Tomcat). The cross context issue (and binding portlet session to
servlet context) needs to be fixed for Pluto 1.1.
4. Some new features should be added to the admin app, including the
administration of authenticated users, user information attributes, and
portal layout management.
Mmm... the admin app seems to be a very interesting mission. :-)
Thanks to all of you for your advice.
Regards.
--
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
Re: [Norton AntiSpam] Re: refactoration of Pluto Admin 1.1
Posted by Zhong ZHENG <he...@gmail.com>.
Hi Ate,
Thank you very much for the advice. I've checked out the source code of
portals-bridges/struts, and will take a look at it in the following days. In
fact, the session binding problem in Pluto 1.1 comes from the cross context:
in the processAction() method, portlet session is bound to the portal's
servlet context, while in the render() method, portlet session is bound to
the portlet app's servlet context.
I will check that issue on Pluto 1.0.1.
Regards.
2005/9/5, Ate Douma <at...@douma.nu>:
>
> Zhong ZHENG wrote:
> > BTW, I've already refactoried the admin app by extracting out the
> > portal-independent framework and trying to make it easier to use. During
> > the refactoration, I referred to the implementation of Struts 1.2.7. Now
> > the small portlet framework looks quite like Struts, but is much
> > simpler, since lots of Struts features are not necessary to the admin
> app.
> >
> > 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.
> Zheng,
>
> I'm the creator of the Struts Bridge which I use for several projects
> using Jetspeed-2
> and I never encountered your session binding problem.
> But, Jetspeed-2 uses the Pluto 1.0.1-rc4 container and maybe you can test
> your
> session problem against that container?
> I know you want this working in Pluto 1.1, but then at least we have a
> better idea where
> to look for the problem.
>
> Ate
>
>
--
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
Re: [Norton AntiSpam] Re: refactoration of Pluto Admin 1.1
Posted by Ate Douma <at...@douma.nu>.
Zhong ZHENG wrote:
> BTW, I've already refactoried the admin app by extracting out the
> portal-independent framework and trying to make it easier to use. During
> the refactoration, I referred to the implementation of Struts 1.2.7. Now
> the small portlet framework looks quite like Struts, but is much
> simpler, since lots of Struts features are not necessary to the admin app.
>
> 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.
Zheng,
I'm the creator of the Struts Bridge which I use for several projects using Jetspeed-2
and I never encountered your session binding problem.
But, Jetspeed-2 uses the Pluto 1.0.1-rc4 container and maybe you can test your
session problem against that container?
I know you want this working in Pluto 1.1, but then at least we have a better idea where
to look for the problem.
Ate
>
>
> 2005/9/5, Zhong ZHENG <heavyzheng@gmail.com <ma...@gmail.com>>:
>
> 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, CDoremus@hannaford.com <ma...@hannaford.com> <
> CDoremus@hannaford.com <ma...@hannaford.com>>:
>
>
> 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 <heavyzheng@gmail.com <ma...@gmail.com>>*
>
> 09/03/2005 01:12 PM
> Please respond to
> pluto-dev@portals.apache.org <ma...@portals.apache.org>
>
>
>
> To
> pluto-dev mailing list <pluto-dev@portals.apache.org
> <ma...@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://heavyz.blogspot.com>
> http://spaces.msn.com/members/zhengzhong
>
>
>
>
>
> --
>
> 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
>
>
Re: refactoration of Pluto Admin 1.1
Posted by Zhong ZHENG <he...@gmail.com>.
Hi,
I've just attached the admin app as well as a simple framework I implemented
last week as a zip file to JIRA:
http://issues.apache.org/jira/browse/PLUTO-160
The admin is far from complete. The goal of this attachment is just to
express a global idea. I am waiting for your opinions.
Regards.
--
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
Re: refactoration of Pluto Admin 1.1
Posted by Zhong ZHENG <he...@gmail.com>.
BTW, I've already refactoried the admin app by extracting out the
portal-independent framework and trying to make it easier to use. During the
refactoration, I referred to the implementation of Struts 1.2.7. Now the
small portlet framework looks quite like Struts, but is much simpler, since
lots of Struts features are not necessary to the admin app.
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 <he...@gmail.com>:
>
> 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, CDoremus@hannaford.com <CD...@hannaford.com>:
> >
> >
> > 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 <he...@gmail.com>*
> >
> > 09/03/2005 01:12 PM Please respond to
> > pluto-dev@portals.apache.org
> >
> > To
> > pluto-dev mailing list <pl...@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
>
>
>
--
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
Re: refactoration of Pluto Admin 1.1
Posted by "David H. DeWolf" <dd...@apache.org>.
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, CDoremus@hannaford.com <ma...@hannaford.com>
> <CDoremus@hannaford.com <ma...@hannaford.com>>:
>
>
> 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 <heavyzheng@gmail.com <ma...@gmail.com>>*
>
> 09/03/2005 01:12 PM
> Please respond to
> pluto-dev@portals.apache.org <ma...@portals.apache.org>
>
>
>
> To
> pluto-dev mailing list <pluto-dev@portals.apache.org
> <ma...@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
>
>
Re: refactoration of Pluto Admin 1.1
Posted by CD...@hannaford.com.
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 <he...@gmail.com>
09/05/2005 11:22 AM
Please respond to
pluto-dev@portals.apache.org
To
pluto-dev@portals.apache.org
cc
Subject
Re: refactoration of Pluto Admin 1.1
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, CDoremus@hannaford.com <CD...@hannaford.com>:
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 <he...@gmail.com>
09/03/2005 01:12 PM
Please respond to
pluto-dev@portals.apache.org
To
pluto-dev mailing list <pl...@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
--
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
Re: refactoration of Pluto Admin 1.1
Posted by Zhong ZHENG <he...@gmail.com>.
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, CDoremus@hannaford.com <CD...@hannaford.com>:
>
>
> 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 <he...@gmail.com>*
>
> 09/03/2005 01:12 PM Please respond to
> pluto-dev@portals.apache.org
>
> To
> pluto-dev mailing list <pl...@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
Re: refactoration of Pluto Admin 1.1
Posted by CD...@hannaford.com.
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 <he...@gmail.com>
09/03/2005 01:12 PM
Please respond to
pluto-dev@portals.apache.org
To
pluto-dev mailing list <pl...@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