portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Chanezon <Patrick.Chane...@Sun.COM>
Subject Re: [portlets] Re: Client Side Scripting - new DOM?
Date Tue, 25 Nov 2003 17:08:58 GMT
I think you're mixing things up.

W3C DOM <http://www.w3.org/DOM/> is:
"a platform- and language-neutral interface that will allow programs and 
scripts to dynamically access and update the content, structure and 
style of documents. The document can be further processed and the 
results of that processing can be incorporated back into the presented 

JSR 168 <http://www.jcp.org/en/jsr/detail?id=168>, is just a java 
specification for server side java components
"To enable interoperability between Portlets and Portals, this 
specification will define a set of APIs for Portal computing addressing 
the areas of aggregation, personalization, presentation and security."

These specifications do not play a role in the same layer in a Portal 
architecture, and they are very different in nature.

If you want to do some client side scripting in your Portal, you can do 
so, by having your Portal server and Portlets generate the right 
javascript and XHTML, and adding a javascript library that will mind the 
gap between client side and server side processing, maybe using a 
command pattern for state changes, and certainly using a naming 
convention, or XPath, for mapping server side elements to client side 
DOM elements. Even with that you'd have to create some Portal server 
specific commands and maybe control servlet on the server side, to 
process your client side commands, because the current rev of JSR 168 
doesn't address aggregation.
However, I haven't seen enough implementation of this kind of 
architecture to mandate a standardization of its components.

The best thing to do if you want to see this kind of architecture taking 
off today is to create some code that implements it :-)
A good first step in this direction is David Sean Taylor's drag and drop 
customizer for Jetspeed 
announced in the list 3 weeks ago.
But as you'll see in the mails, it's specific to the Jetspeed Portal, 
and works only on IE6 and a recent Moz: devil's in the details :-)


PS: congrats for http://portlets.blogspot.com/
It's a good start, and I look forward to see more content coming to it.
You should have a RSS feed for it though.

Punit Pandey wrote:

> Dear Mr. Alejandro / Stefan,
> I see a strong possibility of some portlets related client side technology
> in future. The DOM is designed keeping full page/ window in mind so it is
> not directly usable, as such, with portlets. There can be various issues
> pertaining to it. A developer looses tight-controls that are easily
> available with existing old web technologies like JSP/JavaScript. It is
> difficult to perform general tasks like validations, placing dynamic 
> content
> etc. with ease using portlets. I don't know whether I am thinking weird or
> not, but I guess, that there will be a need of redesigning the DOM, in 
> case
> of success of portlets.
> I am sure it is time for biggies like IBM, Sun, W3C and Microsoft etc. to
> think in this direction. I see it as a next level of standardization after
> JSR 168.
> Also hope to get views of experts in portlets yahoogroups.
> Regards,
> Punit Pandey
> ----- Original Message -----
> From: "Stefan Hepper" <sthepper@de.ibm.com>
> To: "Punit Pandey" <pandeypunit@hotmail.com>
> Cc: <jsr-168-comments@sun.com>; "portlets" <portlets@yahoogroups.com>
> Sent: Monday, November 24, 2003 3:39 PM
> Subject: Re: Client Side Scripting
> >
> > Hi,
> > this is done to allow the portlet to produce output, like a changed 
> title
> > bar or some minimal output (minimized does not require not produce no
> > output).
> >
> > Regards,
> >     Alejandro / Stefan
> >     JSR 168 co-leads
> >
> >
> > "Punit Pandey" <pandeypunit@hotmail.com> wrote on 21/11/2003 08:33:21:
> >
> > > Hello,
> > >
> > > I have seen in JRS 168 specification that for even a single
> > > minimize, we have to post all data to server and get that back to
> > > the client (refresh). Why this strategy been opted? I think that for
> > > minimizing portlets on screens, client side scripting (JavaScript)
> > > is better as it will not refresh the whole page. Why we are moving
> > > to server side architecture for client side events? What are the
> > > architectural decisions behind it?
> > >
> > > Regards,
> > >
> > > Punit Pandey
> >
> >
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service 
> <http://docs.yahoo.com/info/terms/>.

Patrick Chanezon, Sun ONE Portal Server - Software Architect
Sun Microsystems - http://www.chanezon.com/pat
Opinions are my own.

"Computer science is no more about computers than astronomy is about telescopes." 
E.W. Dijkstra 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message