Punit, 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 page."
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 <http://www.mail-archive.com/[EMAIL PROTECTED]/msg10242.html>, 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 :-)
P@
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" <[EMAIL PROTECTED]> To: "Punit Pandey" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "portlets" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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
