You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by "Luta, Raphael (VUN)" <Ra...@groupvu.Com> on 2003/08/06 17:12:08 UTC
RE : JSR-168 Article Part 1 in JavaWorld
De : Gerry Reno [mailto:grenoml@yahoo.com]
>
> I just finished reading the article " Introducing the
> Portlet Specification, Part 1" in JavaWorld. I was hoping to
> find there some latitude in the portlet spec that would allow
> for a portlet interaction model such as I had proposed to the
> JSR-168 team in response to the public release of the spec
> and in these two threads:
> http://marc.theaimsgroup.com/?l=jetspeed-user&m=105850057414235&w=2
>
> http://marc.theaimsgroup.com/?l=jetspeed-user&m=105846310309122&w=2
>
> <snip>
>
If I understand correctly your request in regards to the
JSR 168, you would like to be able to develop a client based portal
that leverages the portlet components developped against the JSR168
API. Is that correct ?
I think that what you can do in this case is implementing
a portal "server" on the client, with client side technologies that
interact with a remote portlet container over the network, for example
through WSRP. In such a setup, your client can control exactly the
aggregation behavior and still leverage any JSR 168 portlets through
WSRP.
Since JSR 168 assumes a server-based aggregation process, it can not
answer alone your requirement but OTOH I don't think it's a showstopper
since WSRP will perfectly handle this requirement.
Am I missing something here ?
--
Raphaël Luta - raphael@apache.org
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/
**********************************************
Vivendi Universal - HTTP://www.vivendiUniversal.com:
The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged
material of Vivendi Universal which is for the exclusive use of the
individual designated above as the recipient. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by persons or entities other than the intended recipient
is prohibited. If you received this in error, please contact immediately
the sender by returning e-mail and delete the material from any computer.
If you are not the specified recipient, you are hereby notified that all
disclosure, reproduction, distribution or action taken on the basis of this
message is prohibited.
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
-trying to tie this linkage back to the original thread -
>De : Gerry Reno [mailto:grenoml@yahoo.com]
>>
>> Hi Raphael,
>>
>> --- "Luta, Raphael (VUN)" <Ra...@groupvu.Com> wrote:
>> >
>> > If I understand correctly your request in regards to the
>> > JSR 168, you would like to be able to develop a client based
portal
>> > that leverages the portlet components developped against the
JSR168
>> > API. Is that correct ?
>> >
>> > I think that what you can do in this case is implementing
>> > a portal "server" on the client, with client side technologies
that
>> > interact with a remote portlet container over the network,
>> for example
>> > through WSRP. In such a setup, your client can control exactly the
>> > aggregation behavior and still leverage any JSR 168 portlets
through
>> > WSRP.
>> >
>> > Since JSR 168 assumes a server-based aggregation process,
>> it can not
>> > answer alone your requirement but OTOH I don't think it's a
>> > showstopper since WSRP will perfectly handle this requirement.
>> >
>> > Am I missing something here ?
>> >
>>
>> Are you suggesting that in order to accomodate client-side
>> technologies that a browser plugin 'portal server' would be
>> necessary?
>> Users would reject this outright. I really don't see how
>> this would solve the problem. It is the whole interaction
>> model that is the problem, not where the 'portal server' lives.
>>
>No, I don't think you need a plug-in, you just need to write
>in Javascript the code that will actually aggregate the content on
>the client instead of aggergating on the server.
>In such a model, you're really back to standard client/server model
>where most of the intelligence is on the client. Such a process flow
>could be:
>clients open up 2 frames/iframes/windows (1 of which is hidden from
the
>user with a 0 size or whatever trick you fancy):
>1st frame loads from HTTP server the JS/applet code that will be the
>portal server and starts displaying the portal page
>The JS code fetches the PSML (or equivalent) information from the
>portal server and loads it into the second frame, then it parses the
>XML information through DOM and activates remote portlet through
>WSRP as needed.
>If you need to save information to a remote server (liek storing user
>preferences), you can do it either through HTTP POST or directly with
>a SOAP request.
All I see this doing is moving around the portal server and playing
tricks with the markup. I think we would need to see some type of an
example to examine whether this offered any possibilities.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
-trying to tie this linkage back to the original thread -
>De : Gerry Reno [mailto:grenoml@yahoo.com]
>>
>> Hi Raphael,
>>
>> --- "Luta, Raphael (VUN)" <Ra...@groupvu.Com> wrote:
>> >
>> > If I understand correctly your request in regards to the
>> > JSR 168, you would like to be able to develop a client based
portal
>> > that leverages the portlet components developped against the
JSR168
>> > API. Is that correct ?
>> >
>> > I think that what you can do in this case is implementing
>> > a portal "server" on the client, with client side technologies
that
>> > interact with a remote portlet container over the network,
>> for example
>> > through WSRP. In such a setup, your client can control exactly the
>> > aggregation behavior and still leverage any JSR 168 portlets
through
>> > WSRP.
>> >
>> > Since JSR 168 assumes a server-based aggregation process,
>> it can not
>> > answer alone your requirement but OTOH I don't think it's a
>> > showstopper since WSRP will perfectly handle this requirement.
>> >
>> > Am I missing something here ?
>> >
>>
>> Are you suggesting that in order to accomodate client-side
>> technologies that a browser plugin 'portal server' would be
>> necessary?
>> Users would reject this outright. I really don't see how
>> this would solve the problem. It is the whole interaction
>> model that is the problem, not where the 'portal server' lives.
>>
>No, I don't think you need a plug-in, you just need to write
>in Javascript the code that will actually aggregate the content on
>the client instead of aggergating on the server.
>In such a model, you're really back to standard client/server model
>where most of the intelligence is on the client. Such a process flow
>could be:
>clients open up 2 frames/iframes/windows (1 of which is hidden from
the
>user with a 0 size or whatever trick you fancy):
>1st frame loads from HTTP server the JS/applet code that will be the
>portal server and starts displaying the portal page
>The JS code fetches the PSML (or equivalent) information from the
>portal server and loads it into the second frame, then it parses the
>XML information through DOM and activates remote portlet through
>WSRP as needed.
>If you need to save information to a remote server (liek storing user
>preferences), you can do it either through HTTP POST or directly with
>a SOAP request.
All I see this doing is moving around the portal server and playing
tricks with the markup. I think we would need to see some type of an
example to examine whether this offered any possibilities.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Hi Serge,
--- Serge Huber <sh...@jahia.com> wrote:
> At 08:32 AM 8/6/2003 -0700, you wrote:
> >Hi Raphael,
> >
> >--- "Luta, Raphael (VUN)" <Ra...@groupvu.Com> wrote:
> > >
> > > If I understand correctly your request in regards to the
> > > JSR 168, you would like to be able to develop a client based
> portal
> > > that leverages the portlet components developped against the
> JSR168
> > > API. Is that correct ?
> > >
> > > I think that what you can do in this case is implementing
> > > a portal "server" on the client, with client side technologies
> that
> > > interact with a remote portlet container over the network, for
> > > example
> > > through WSRP. In such a setup, your client can control exactly
> the
> > > aggregation behavior and still leverage any JSR 168 portlets
> through
> > > WSRP.
> > >
> > > Since JSR 168 assumes a server-based aggregation process, it can
> not
> > > answer alone your requirement but OTOH I don't think it's a
> > > showstopper
> > > since WSRP will perfectly handle this requirement.
> > >
> > > Am I missing something here ?
> > >
> >
> > Are you suggesting that in order to accomodate client-side
> >technologies that a browser plugin 'portal server' would be
> necessary?
> >Users would reject this outright. I really don't see how this would
> >solve the problem. It is the whole interaction model that is the
> >problem, not where the 'portal server' lives.
>
> Actually I think Raphael has an interesting idea. Let's suppose
> you're
> using Mozilla as a client technology. You could design a XUL client
> that
> would use LiveConnect to do WSRP requests to a WSRP compliant server
> (Jetspeed 2?). Within this server the interface of JSR-168 could be
> used to
> communicate with the portlets.
>
> But I also have some ideas for improvements for JSR-168, but I
> believe it
> can come later. The politics behind this JSR have slowed it down to a
>
> crawl, and I think it's is best for version 1.0 to get out the door
> as soon
> as possible, so that work may start on the foundation that's been
> laid out.
>
I must respectfully disagree that it's best to just push this spec
out the door. You can't position yourself for the future if the
foundation is not set properly and I am asserting that it is not.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Hi Serge,
--- Serge Huber <sh...@jahia.com> wrote:
> At 08:32 AM 8/6/2003 -0700, you wrote:
> >Hi Raphael,
> >
> >--- "Luta, Raphael (VUN)" <Ra...@groupvu.Com> wrote:
> > >
> > > If I understand correctly your request in regards to the
> > > JSR 168, you would like to be able to develop a client based
> portal
> > > that leverages the portlet components developped against the
> JSR168
> > > API. Is that correct ?
> > >
> > > I think that what you can do in this case is implementing
> > > a portal "server" on the client, with client side technologies
> that
> > > interact with a remote portlet container over the network, for
> > > example
> > > through WSRP. In such a setup, your client can control exactly
> the
> > > aggregation behavior and still leverage any JSR 168 portlets
> through
> > > WSRP.
> > >
> > > Since JSR 168 assumes a server-based aggregation process, it can
> not
> > > answer alone your requirement but OTOH I don't think it's a
> > > showstopper
> > > since WSRP will perfectly handle this requirement.
> > >
> > > Am I missing something here ?
> > >
> >
> > Are you suggesting that in order to accomodate client-side
> >technologies that a browser plugin 'portal server' would be
> necessary?
> >Users would reject this outright. I really don't see how this would
> >solve the problem. It is the whole interaction model that is the
> >problem, not where the 'portal server' lives.
>
> Actually I think Raphael has an interesting idea. Let's suppose
> you're
> using Mozilla as a client technology. You could design a XUL client
> that
> would use LiveConnect to do WSRP requests to a WSRP compliant server
> (Jetspeed 2?). Within this server the interface of JSR-168 could be
> used to
> communicate with the portlets.
>
> But I also have some ideas for improvements for JSR-168, but I
> believe it
> can come later. The politics behind this JSR have slowed it down to a
>
> crawl, and I think it's is best for version 1.0 to get out the door
> as soon
> as possible, so that work may start on the foundation that's been
> laid out.
>
I must respectfully disagree that it's best to just push this spec
out the door. You can't position yourself for the future if the
foundation is not set properly and I am asserting that it is not.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Serge Huber <sh...@jahia.com>.
At 08:32 AM 8/6/2003 -0700, you wrote:
>Hi Raphael,
>
>--- "Luta, Raphael (VUN)" <Ra...@groupvu.Com> wrote:
> >
> > If I understand correctly your request in regards to the
> > JSR 168, you would like to be able to develop a client based portal
> > that leverages the portlet components developped against the JSR168
> > API. Is that correct ?
> >
> > I think that what you can do in this case is implementing
> > a portal "server" on the client, with client side technologies that
> > interact with a remote portlet container over the network, for
> > example
> > through WSRP. In such a setup, your client can control exactly the
> > aggregation behavior and still leverage any JSR 168 portlets through
> > WSRP.
> >
> > Since JSR 168 assumes a server-based aggregation process, it can not
> > answer alone your requirement but OTOH I don't think it's a
> > showstopper
> > since WSRP will perfectly handle this requirement.
> >
> > Am I missing something here ?
> >
>
> Are you suggesting that in order to accomodate client-side
>technologies that a browser plugin 'portal server' would be necessary?
>Users would reject this outright. I really don't see how this would
>solve the problem. It is the whole interaction model that is the
>problem, not where the 'portal server' lives.
Actually I think Raphael has an interesting idea. Let's suppose you're
using Mozilla as a client technology. You could design a XUL client that
would use LiveConnect to do WSRP requests to a WSRP compliant server
(Jetspeed 2?). Within this server the interface of JSR-168 could be used to
communicate with the portlets.
But I also have some ideas for improvements for JSR-168, but I believe it
can come later. The politics behind this JSR have slowed it down to a
crawl, and I think it's is best for version 1.0 to get out the door as soon
as possible, so that work may start on the foundation that's been laid out.
Regards,
Serge Huber.
- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
www.jahia.org : A collaborative source CMS and Portal Server
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Serge Huber <sh...@jahia.com>.
At 08:32 AM 8/6/2003 -0700, you wrote:
>Hi Raphael,
>
>--- "Luta, Raphael (VUN)" <Ra...@groupvu.Com> wrote:
> >
> > If I understand correctly your request in regards to the
> > JSR 168, you would like to be able to develop a client based portal
> > that leverages the portlet components developped against the JSR168
> > API. Is that correct ?
> >
> > I think that what you can do in this case is implementing
> > a portal "server" on the client, with client side technologies that
> > interact with a remote portlet container over the network, for
> > example
> > through WSRP. In such a setup, your client can control exactly the
> > aggregation behavior and still leverage any JSR 168 portlets through
> > WSRP.
> >
> > Since JSR 168 assumes a server-based aggregation process, it can not
> > answer alone your requirement but OTOH I don't think it's a
> > showstopper
> > since WSRP will perfectly handle this requirement.
> >
> > Am I missing something here ?
> >
>
> Are you suggesting that in order to accomodate client-side
>technologies that a browser plugin 'portal server' would be necessary?
>Users would reject this outright. I really don't see how this would
>solve the problem. It is the whole interaction model that is the
>problem, not where the 'portal server' lives.
Actually I think Raphael has an interesting idea. Let's suppose you're
using Mozilla as a client technology. You could design a XUL client that
would use LiveConnect to do WSRP requests to a WSRP compliant server
(Jetspeed 2?). Within this server the interface of JSR-168 could be used to
communicate with the portlets.
But I also have some ideas for improvements for JSR-168, but I believe it
can come later. The politics behind this JSR have slowed it down to a
crawl, and I think it's is best for version 1.0 to get out the door as soon
as possible, so that work may start on the foundation that's been laid out.
Regards,
Serge Huber.
- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
www.jahia.org : A collaborative source CMS and Portal Server
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: RE : JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Hi Raphael,
--- "Luta, Raphael (VUN)" <Ra...@groupvu.Com> wrote:
>
> If I understand correctly your request in regards to the
> JSR 168, you would like to be able to develop a client based portal
> that leverages the portlet components developped against the JSR168
> API. Is that correct ?
>
> I think that what you can do in this case is implementing
> a portal "server" on the client, with client side technologies that
> interact with a remote portlet container over the network, for
> example
> through WSRP. In such a setup, your client can control exactly the
> aggregation behavior and still leverage any JSR 168 portlets through
> WSRP.
>
> Since JSR 168 assumes a server-based aggregation process, it can not
> answer alone your requirement but OTOH I don't think it's a
> showstopper
> since WSRP will perfectly handle this requirement.
>
> Am I missing something here ?
>
Are you suggesting that in order to accomodate client-side
technologies that a browser plugin 'portal server' would be necessary?
Users would reject this outright. I really don't see how this would
solve the problem. It is the whole interaction model that is the
problem, not where the 'portal server' lives.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: RE : JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Hi Raphael,
--- "Luta, Raphael (VUN)" <Ra...@groupvu.Com> wrote:
>
> If I understand correctly your request in regards to the
> JSR 168, you would like to be able to develop a client based portal
> that leverages the portlet components developped against the JSR168
> API. Is that correct ?
>
> I think that what you can do in this case is implementing
> a portal "server" on the client, with client side technologies that
> interact with a remote portlet container over the network, for
> example
> through WSRP. In such a setup, your client can control exactly the
> aggregation behavior and still leverage any JSR 168 portlets through
> WSRP.
>
> Since JSR 168 assumes a server-based aggregation process, it can not
> answer alone your requirement but OTOH I don't think it's a
> showstopper
> since WSRP will perfectly handle this requirement.
>
> Am I missing something here ?
>
Are you suggesting that in order to accomodate client-side
technologies that a browser plugin 'portal server' would be necessary?
Users would reject this outright. I really don't see how this would
solve the problem. It is the whole interaction model that is the
problem, not where the 'portal server' lives.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Hi Raphael,
--- "Luta, Raphael (VUN)" <Ra...@groupvu.Com> wrote:
>
> If I understand correctly your request in regards to the
> JSR 168, you would like to be able to develop a client based portal
> that leverages the portlet components developped against the JSR168
> API. Is that correct ?
>
> I think that what you can do in this case is implementing
> a portal "server" on the client, with client side technologies that
> interact with a remote portlet container over the network, for
> example
> through WSRP. In such a setup, your client can control exactly the
> aggregation behavior and still leverage any JSR 168 portlets through
> WSRP.
>
> Since JSR 168 assumes a server-based aggregation process, it can not
> answer alone your requirement but OTOH I don't think it's a
> showstopper
> since WSRP will perfectly handle this requirement.
>
> Am I missing something here ?
>
Are you suggesting that in order to accomodate client-side
technologies that a browser plugin 'portal server' would be necessary?
Users would reject this outright. I really don't see how this would
solve the problem. It is the whole interaction model that is the
problem, not where the 'portal server' lives.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Hi Raphael,
--- "Luta, Raphael (VUN)" <Ra...@groupvu.Com> wrote:
>
> If I understand correctly your request in regards to the
> JSR 168, you would like to be able to develop a client based portal
> that leverages the portlet components developped against the JSR168
> API. Is that correct ?
>
> I think that what you can do in this case is implementing
> a portal "server" on the client, with client side technologies that
> interact with a remote portlet container over the network, for
> example
> through WSRP. In such a setup, your client can control exactly the
> aggregation behavior and still leverage any JSR 168 portlets through
> WSRP.
>
> Since JSR 168 assumes a server-based aggregation process, it can not
> answer alone your requirement but OTOH I don't think it's a
> showstopper
> since WSRP will perfectly handle this requirement.
>
> Am I missing something here ?
>
Are you suggesting that in order to accomodate client-side
technologies that a browser plugin 'portal server' would be necessary?
Users would reject this outright. I really don't see how this would
solve the problem. It is the whole interaction model that is the
problem, not where the 'portal server' lives.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com