Dear Mr. Chanezon and friends, Thanks for the appreciation for my blog. My present service (blogger) does not provide free RSS but I'll try to add it in future. If possible, please keep me and this group updated about changes in portlets technology.
Another thing, what you (and other experts in the group) think about a new DOM keeping 'parts of screen' in mind rather 'full page'? I am talking about future client-side counterpart of platform independent portlets. (I guess that Microsoft too will come up with similar technology, if not already done that.) Regards, Punit Pandey ----- Original Message ----- From: "Patrick Chanezon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Stefan Hepper" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Jetspeed Dev" <[EMAIL PROTECTED]> Sent: Tuesday, November 25, 2003 10:38 PM Subject: Re: [portlets] Re: Client Side Scripting - new DOM? > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
