[EMAIL PROTECTED] 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" <[EMAIL PROTECTED]>*
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 <[EMAIL PROTECTED]
<mailto:[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.sourceforge.net>
> http://heavyz.blogspot.com
> http://spaces.msn.com/members/zhengzhong
>
>
