portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Kuebler <tkueb...@cisco.com>
Subject RE: Jetspeed2 development
Date Thu, 23 Oct 2003 21:48:30 GMT

I continue to believe that the Portlet idea should simply implement the 
controller paradigm of the MVC instead of being some class that needs 
extending by the typical web developer just to create a html fragment.  Of 
course I haven't had time to look at J2 for the impedance mismatch with J1 
yet. Just like servlets are best served by something like Struts, I believe 
portlets are best served by something like the MVCPorlet idea.  Maybe the 
J2 core doesn't deal with that, although as a portal implementation it will 
have to deal with that idea sooner or later to reach maturity imho.  I 
really need to make the time to look at j2.   I'm also unclear how the View 
Processors are separate from the idea of the MVCPortlet.

Another proposal: I know the portlet spec specifies only one event per 
request (in regards to individual portlets),  but if you look at a portal 
in whole as a windowing environment an AWT style event model comes to mind 
as the logical choice.  There are numerous 'windows/components' in the 
'window environment'.  I would really like to see the AWT style model of 
event handling to come into play with the different phases of page 
rendering (session/request/page/layout/screen) treated as 'components' that 
can register and listen for 'events' generated by the 'user 
input(request)'.  This might already be in J2, hope so. :)


-tk


At 05:29 PM 10/23/2003 -0400, Weaver, Scott wrote:
>Actually, the view processors would be very helpful.  I definitely want to 
>move them over.  Not so much the MVC portlet though, that is more for 
>portlet application developers and not the J2 core.
>
>Regards,
>*================================*
>| Scott T Weaver                 |
>| <weaver@apache.org>            |
>| Apache Jetspeed Portal Project |
>| Apache Pluto Portlet Container |
>*================================*
>
> > -----Original Message-----
> > From: Todd Kuebler [mailto:tkuebler@cisco.com]
> > Sent: Thursday, October 23, 2003 5:24 PM
> > To: Jetspeed Developers List
> > Subject: RE: Jetspeed2 development
> >
> >
> > Are there any plans on 'porting' the MVCPortlet?  I haven't had time to
> > look at the impedance missmatch with Jetspeed2 yet so don't even know if
> > it
> > is possible/desireable.
> >
> > -tk
> >
> >
> > At 05:24 PM 10/23/2003 -0400, Weaver, Scott wrote:
> > >Hi Ken,
> > >
> > >Give me a day or two to come up with some "minor" things.  Porting is a
> > >good idea though.  Maybe start with the WebsurferPortlet.
> > >
> > >Regards,
> > >*================================*
> > >| Scott T Weaver                 |
> > >| <weaver@apache.org>            |
> > >| Apache Jetspeed Portal Project |
> > >| Apache Pluto Portlet Container |
> > >*================================*
> > >
> > > > -----Original Message-----
> > > > From: Ken Geis [mailto:kgeis@galenworks.com]
> > > > Sent: Thursday, October 23, 2003 4:36 PM
> > > > Cc: jetspeed-dev@jakarta.apache.org
> > > > Subject: Re: Jetspeed2 development
> > > >
> > > > Scott, I see most of the things you describe as being the
> > responsibility
> > > > of core developers.  I could hope to help with that sort of thing, but
> > I
> > > > was thinking of more grunt-work type stuff, small units of work
> > > > requiring little design where a developer can leverage existing work
> > > > (e.g. "using the implementation of X as an example, implement Y.")
> > Like
> > > > porting particular portlets from Jetspeed1 to Jetspeed2.
> > > >
> > > > Scott Weaver wrote:
> > > > >>To follow that up, where can the more casual contributor be of
use
> > right
> > > > >>now?
> > > > >
> > > > >
> > > > > We need to put together a more up to date TODO list.  But here are
> > so
> > > > open things off the top of my head:
> > > > >
> > > > > - Security
> > > > > - Themes/Skins
> > > > > - New aggregation engine (David Taylor is currently working on an
> > > > >   asynchronous rendering aggregator)
> > > > > - Page registry (replaces psml, is not subject-specific like PSML
> > was)
> > > > > - Profiling.  David Le Strat has put together a proposal and code
> > for
> > > > this.
> > > > >   The proposal is under design-docs/proposals.
> > > > > - Struts integration.
> > > > > - New component framework to replace Fulcrum (and possibly CPS which
> > is
> > > > >   currently a fa├žade over Fulcrum)
> > > > > - Customization interfaces
> > > > > - Admin interfaces
> > > > >
> > > > > That is all I can think of off the top of my head.  I will try to
> > get
> > > > these updated to the CVS.
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message