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 "David H. DeWolf" <dd...@apache.org> on 2005/09/17 01:27:11 UTC
[Vote] 1.1 Admin Portlet Framework?
Zheng had put together an initial framework for the Admin portlets. In
essence, the framework was as scaled down version of struts -
specifically designed for portlets. While it was great work, I am
personally opposed to hosting a framework (no matter how scaled down) in
pluto, simply because I could see maintenance of the framework alone
growing out of control quickly. Enhancement requests would role in
simply due to the fact that others are using the framework for different
portlets. . . .
I'm curious what others thoughts are. IMHO we have 3 choices. Please
indicate your preference:
[ ] Utilize an existing framework for the admin portlet. Why rewrite?
[ ] Roll our own framework for the admin portlet. Why not?
[ ] Utilize a simple controller portlet. Simplicity is best!
Thanks,
David
Re: [Vote] 1.1 Admin Portlet Framework?
Posted by "David H. DeWolf" <dd...@apache.org>.
Santiago Gala wrote:
> El vie, 16-09-2005 a las 19:27 -0400, David H. DeWolf escribió:
>
>>Zheng had put together an initial framework for the Admin portlets. In
>>essence, the framework was as scaled down version of struts -
>>specifically designed for portlets. While it was great work, I am
>>personally opposed to hosting a framework (no matter how scaled down) in
>>pluto, simply because I could see maintenance of the framework alone
>>growing out of control quickly. Enhancement requests would role in
>>simply due to the fact that others are using the framework for different
>>portlets. . . .
>>
>>I'm curious what others thoughts are. IMHO we have 3 choices. Please
>>indicate your preference:
>>
>>[ ] Utilize an existing framework for the admin portlet. Why rewrite?
>>[ ] Roll our own framework for the admin portlet. Why not?
>>[ ] Utilize a simple controller portlet. Simplicity is best!
>>
>
>
> I'm -1 WRT rolling a framework for it, with basically your arguments.
>
> I just wanted to point that, in case pluto wants to use something beyond
> a controller portlet, the portals-bridges module
> ( http://svn.apache.org/repos/asf/portals/bridges/trunk/ ) offers
> several possibilities: velocity, struts, jsf, perl, php and soon python.
Part of me wants to utilize one of the the bridges frameworks just so we
have some inter-project cooperation. I guess I'd be a +1 for either the
"simple" approach or for the bridges approach.
>
> This code is (if it isn't, it should be) completely free of dependencies
> in jetspeed, just portlet-api, and is devoted to implementing frameworks
> for portlet development using web technologies, such as Faces, Struts,
> etc. Most bridges have little code, just enough to offer basic JSR-168
> services to other technologies' developers.
I'm not that familiar with bridges so thanks for the heads up.
>
> As the current policy in the Apache Portals project is to grant commit
> rights to the whole project, any pluto committer has rights to commit
> there.
Really? That's also good to know. I'm starting to like this approach
more and more. Anyone else?
David
>
> What do you think?
>
>
>>Thanks,
>>
>>David
>>
>
>
> Regards
> Santiago
Re: [Vote] 1.1 Admin Portlet Framework?
Posted by Santiago Gala <sg...@apache.org>.
El vie, 16-09-2005 a las 19:27 -0400, David H. DeWolf escribió:
> Zheng had put together an initial framework for the Admin portlets. In
> essence, the framework was as scaled down version of struts -
> specifically designed for portlets. While it was great work, I am
> personally opposed to hosting a framework (no matter how scaled down) in
> pluto, simply because I could see maintenance of the framework alone
> growing out of control quickly. Enhancement requests would role in
> simply due to the fact that others are using the framework for different
> portlets. . . .
>
> I'm curious what others thoughts are. IMHO we have 3 choices. Please
> indicate your preference:
>
> [ ] Utilize an existing framework for the admin portlet. Why rewrite?
> [ ] Roll our own framework for the admin portlet. Why not?
> [ ] Utilize a simple controller portlet. Simplicity is best!
>
I'm -1 WRT rolling a framework for it, with basically your arguments.
I just wanted to point that, in case pluto wants to use something beyond
a controller portlet, the portals-bridges module
( http://svn.apache.org/repos/asf/portals/bridges/trunk/ ) offers
several possibilities: velocity, struts, jsf, perl, php and soon python.
This code is (if it isn't, it should be) completely free of dependencies
in jetspeed, just portlet-api, and is devoted to implementing frameworks
for portlet development using web technologies, such as Faces, Struts,
etc. Most bridges have little code, just enough to offer basic JSR-168
services to other technologies' developers.
As the current policy in the Apache Portals project is to grant commit
rights to the whole project, any pluto committer has rights to commit
there.
What do you think?
> Thanks,
>
> David
>
Regards
Santiago
--
VP and Chair, Apache Portals (http://portals.apache.org)
Apache Software Foundation
Re: [Vote] 1.1 Admin Portlet Framework?
Posted by Zhong ZHENG <he...@gmail.com>.
[x] Utilize a simple controller portlet. Simplicity is best!
Simple is beautiful! I would like to take charge of the redesign of the
admin app if you also agree to the last choice. I think the testsuite
framework is a good example.
Regards.
2005/9/17, David H. DeWolf <dd...@apache.org>:
>
> Zheng had put together an initial framework for the Admin portlets. In
> essence, the framework was as scaled down version of struts -
> specifically designed for portlets. While it was great work, I am
> personally opposed to hosting a framework (no matter how scaled down) in
> pluto, simply because I could see maintenance of the framework alone
> growing out of control quickly. Enhancement requests would role in
> simply due to the fact that others are using the framework for different
> portlets. . . .
>
> I'm curious what others thoughts are. IMHO we have 3 choices. Please
> indicate your preference:
>
> [ ] Utilize an existing framework for the admin portlet. Why rewrite?
> [ ] Roll our own framework for the admin portlet. Why not?
> [ ] Utilize a simple controller portlet. Simplicity is best!
>
> Thanks,
>
> David
>
>
--
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: [Vote] 1.1 Admin Portlet Framework?
Posted by Zhong ZHENG <he...@gmail.com>.
2005/9/23, David H. DeWolf <dd...@apache.org>:
>
>
> Ideally, all of us would contribute to the effort. I think we're
> starting to build a stronger community and am looking forward to more
> and more collaboration and less isolated development.
Got that point! That's the way how OSS communities work.
(I know Craig didn't necisarily mean to suggest that the admin portlet
> is "controlled" by a main developer, but I just wanted to clarify for
> those new to the community.)
>
> > /Craig
> >
>
>
--
ZHENG Zhong
1 Avenue Alphand
75116 Paris, France
+33 6 76 80 45 90
Re: [Vote] 1.1 Admin Portlet Framework?
Posted by Santiago Gala <sg...@apache.org>.
El mar, 27-09-2005 a las 11:00 +0200, Raphaël Luta escribió:
> David H. DeWolf wrote:
> > CDoremus@hannaford.com wrote:
> >> "David H. DeWolf" <dd...@apache.org> wrote on 09/16/2005 07:27:11 PM:
> >>
> >> > [ ] Utilize an existing framework for the admin portlet. Why rewrite?
> >> > [ ] Roll our own framework for the admin portlet. Why not?
> >> [X] Utilize a simple controller portlet. Simplicity is best!
> >>
>
> You could add an additionnal option: roll your own framework but contribute
> it in bridges rather than directly in pluto so that it gets more exposure
> as a stand-alone framework (and also decouple the container from the framework).
>
> >> I'd rather not add any other complexity to the mix including
> >> portals-bridges.
> >>
>
> Bridges does not really add complexity since it releases individual
> bridge artefacts and not a complete heavyweight binary so you could
> simply use a struts-bridge if that's waht you aim for or roll you own
> there and depend only on your framework.
>
For instance, without taking into account the proper framework
dependencies (struts, jsf, velocity, jython, etc.):
14243 sep 26 23:11 common/target/portals-bridges-common-0.4-SNAPSHOT.jar
28730 sep 26 23:11
frameworks/target/portals-bridges-frameworks-0.4-SNAPSHOT.jar
41893 sep 26 23:12 jsf/target/portals-bridges-jsf-0.4-SNAPSHOT.jar
13746 sep 26 23:12 perl/target/portals-bridges-perl-0.4-SNAPSHOT.jar
11840 sep 26 23:12 php/target/portals-bridges-php-0.4-SNAPSHOT.jar
9361 sep 27 16:49 python/target/portals-bridges-python-0.4-SNAPSHOT.jar
63998 sep 26 23:12
struts/target/portals-bridges-struts-1.2.7-0.4-SNAPSHOT.jar
9099 sep 26 23:11
velocity/target/portals-bridges-velocity-0.4-SNAPSHOT.jar
So they are really lightweight, and the functionality they offer is
basically turning servlet requests into portlet requests and
session/request utilities, plus taglibs or similar framework level
abstractions.
The perl bridge uses jetspeed html rewriter, which is a jetspeed
component that should probably be also taken out from the core (it is
used for proxying requests or adapting external resources). David and
myself were talking informally that it could go under Jakarta Web
Components, I'm not sure they have something for web page scraping.
> I'm aware that Christophe in Graffito is also working on his own
> portlet framework... better to have everyone sharing his thoughts on
> bridges and shows his ideas rather that having several "private" frameworks
> hidden in every portals subproject.
>
Tell him to come to bridges :)
--
VP and Chair, Apache Portals (http://portals.apache.org)
Apache Software Foundation
Re: [Vote] 1.1 Admin Portlet Framework?
Posted by Raphaël Luta <ra...@apache.org>.
David H. DeWolf wrote:
> CDoremus@hannaford.com wrote:
>> "David H. DeWolf" <dd...@apache.org> wrote on 09/16/2005 07:27:11 PM:
>>
>> > Zheng had put together an initial framework for the Admin
>> portlets. In
>> > essence, the framework was as scaled down version of struts -
>> > specifically designed for portlets. While it was great work, I am
>> > personally opposed to hosting a framework (no matter how scaled
>> down) in
>> > pluto, simply because I could see maintenance of the framework alone
>> > growing out of control quickly. Enhancement requests would role in
>> > simply due to the fact that others are using the framework for
>> different
>> > portlets. . . .
>> >
>> > I'm curious what others thoughts are. IMHO we have 3 choices. Please
>> > indicate your preference:
>> >
>> > [ ] Utilize an existing framework for the admin portlet. Why rewrite?
>> > [ ] Roll our own framework for the admin portlet. Why not?
>> [X] Utilize a simple controller portlet. Simplicity is best!
>>
You could add an additionnal option: roll your own framework but contribute
it in bridges rather than directly in pluto so that it gets more exposure
as a stand-alone framework (and also decouple the container from the framework).
>> I'd rather not add any other complexity to the mix including
>> portals-bridges.
>>
Bridges does not really add complexity since it releases individual
bridge artefacts and not a complete heavyweight binary so you could
simply use a struts-bridge if that's waht you aim for or roll you own
there and depend only on your framework.
I'm aware that Christophe in Graffito is also working on his own
portlet framework... better to have everyone sharing his thoughts on
bridges and shows his ideas rather that having several "private" frameworks
hidden in every portals subproject.
>> Zheng is welcome to take over control of the portlet admin app for
>> Pluto 1.1. I'd like to contribute an interface for user management and
>> User Information Attributes.
>
>
> Ideally, all of us would contribute to the effort. I think we're
> starting to build a stronger community and am looking forward to more
> and more collaboration and less isolated development.
>
> (I know Craig didn't necisarily mean to suggest that the admin portlet
> is "controlled" by a main developer, but I just wanted to clarify for
> those new to the community.)
>
+1
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
Re: [Vote] 1.1 Admin Portlet Framework?
Posted by CD...@hannaford.com.
"David H. DeWolf" <dd...@apache.org> wrote on 09/22/2005 09:07:44 PM:
>
>
> CDoremus@hannaford.com wrote:
> >
> > "David H. DeWolf" <dd...@apache.org> wrote on 09/16/2005 07:27:11
PM:
> >
> > > Zheng had put together an initial framework for the Admin portlets.
In
> > > essence, the framework was as scaled down version of struts -
> > > specifically designed for portlets. While it was great work, I am
> > > personally opposed to hosting a framework (no matter how scaled
down) in
> > > pluto, simply because I could see maintenance of the framework
alone
> > > growing out of control quickly. Enhancement requests would role in
> > > simply due to the fact that others are using the framework for
different
> > > portlets. . . .
> > >
> > > I'm curious what others thoughts are. IMHO we have 3 choices.
Please
> > > indicate your preference:
> > >
> > > [ ] Utilize an existing framework for the admin portlet. Why
rewrite?
> > > [ ] Roll our own framework for the admin portlet. Why not?
> > [X] Utilize a simple controller portlet. Simplicity is best!
> >
> > I'd rather not add any other complexity to the mix including
> > portals-bridges.
> >
> > Zheng is welcome to take over control of the portlet admin app for
Pluto
> > 1.1. I'd like to contribute an interface for user management and User
> > Information Attributes.
>
> Ideally, all of us would contribute to the effort. I think we're
> starting to build a stronger community and am looking forward to more
> and more collaboration and less isolated development.
>
> (I know Craig didn't necisarily mean to suggest that the admin portlet
> is "controlled" by a main developer, but I just wanted to clarify for
> those new to the community.)
Of course, we will collaborate, but we shouldn't all work on the same
thing at the same time. Since, Zheng is way ahead of me with work on Pluto
1.1 admin portlets, he should 'lead' (NOT, control) development in that
area. I would like to contribute functionality to administer users and
user information attributes.
I am sorry for the poor choice of words.
/Craig
Re: [Vote] 1.1 Admin Portlet Framework?
Posted by "David H. DeWolf" <dd...@apache.org>.
CDoremus@hannaford.com wrote:
>
> "David H. DeWolf" <dd...@apache.org> wrote on 09/16/2005 07:27:11 PM:
>
> > Zheng had put together an initial framework for the Admin portlets. In
> > essence, the framework was as scaled down version of struts -
> > specifically designed for portlets. While it was great work, I am
> > personally opposed to hosting a framework (no matter how scaled down) in
> > pluto, simply because I could see maintenance of the framework alone
> > growing out of control quickly. Enhancement requests would role in
> > simply due to the fact that others are using the framework for different
> > portlets. . . .
> >
> > I'm curious what others thoughts are. IMHO we have 3 choices. Please
> > indicate your preference:
> >
> > [ ] Utilize an existing framework for the admin portlet. Why rewrite?
> > [ ] Roll our own framework for the admin portlet. Why not?
> [X] Utilize a simple controller portlet. Simplicity is best!
>
> I'd rather not add any other complexity to the mix including
> portals-bridges.
>
> Zheng is welcome to take over control of the portlet admin app for Pluto
> 1.1. I'd like to contribute an interface for user management and User
> Information Attributes.
Ideally, all of us would contribute to the effort. I think we're
starting to build a stronger community and am looking forward to more
and more collaboration and less isolated development.
(I know Craig didn't necisarily mean to suggest that the admin portlet
is "controlled" by a main developer, but I just wanted to clarify for
those new to the community.)
> /Craig
>
Re: [Vote] 1.1 Admin Portlet Framework?
Posted by CD...@hannaford.com.
"David H. DeWolf" <dd...@apache.org> wrote on 09/16/2005 07:27:11 PM:
> Zheng had put together an initial framework for the Admin portlets. In
> essence, the framework was as scaled down version of struts -
> specifically designed for portlets. While it was great work, I am
> personally opposed to hosting a framework (no matter how scaled down) in
> pluto, simply because I could see maintenance of the framework alone
> growing out of control quickly. Enhancement requests would role in
> simply due to the fact that others are using the framework for different
> portlets. . . .
>
> I'm curious what others thoughts are. IMHO we have 3 choices. Please
> indicate your preference:
>
> [ ] Utilize an existing framework for the admin portlet. Why rewrite?
> [ ] Roll our own framework for the admin portlet. Why not?
[X] Utilize a simple controller portlet. Simplicity is best!
I'd rather not add any other complexity to the mix including
portals-bridges.
Zheng is welcome to take over control of the portlet admin app for Pluto
1.1. I'd like to contribute an interface for user management and User
Information Attributes.
/Craig