RE : JSR-168 Article Part 1 in JavaWorld
De : Helmut Tammen [mailto:[EMAIL PROTECTED] Envoyé : samedi 16 août 2003 19:29 À : [EMAIL PROTECTED] Objet : Re: JSR-168 Article Part 1 in JavaWorld Hi, I came a little bit late to this discussion. You should have had a look at the SAP Enterprise Portal (http://www.iviewstudio.com). They already extensively work with iFrames. Each portlet (they call them iViews) is enclosed in an iFrame. And furthermore they have sophisticated client side features like client-side eventing to send messages from one portlet (iView) to another and the client data-bag to exchange data from one portlet to another. snip I just registered to check it out and, of course, it simply doesn't recognize my Mozilla Firebird as a supported client so I get a very ugly site. Thanks for reminding me why I so dislike client-side technologies :) -- Raphaël Luta - [EMAIL PROTECTED] 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE : JSR-168 Article Part 1 in JavaWorld
Raphaël Luta wrote: I just registered to check it out and, of course, it simply doesn't recognize my Mozilla Firebird as a supported client so I get a very ugly site. Thanks for reminding me why I so dislike client-side technologies :) Same with Mozilla1.4 (even without taking the pain to register) Ah, at least I'm glad I finally see a mail here from someone that seems to be *against* iframes ;) (i was evaluating jetspeed, and it seems usability and xhtml compliance are not really taken in account, or is it and i missed a point somewhere?) g - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : RE : JSR-168 Article Part 1 in JavaWorld
De : Gregory Joseph [mailto:[EMAIL PROTECTED] Raphaël Luta wrote: I just registered to check it out and, of course, it simply doesn't recognize my Mozilla Firebird as a supported client so I get a very ugly site. Thanks for reminding me why I so dislike client-side technologies :) Same with Mozilla1.4 (even without taking the pain to register) Ah, at least I'm glad I finally see a mail here from someone that seems to be *against* iframes ;) (i was evaluating jetspeed, and it seems usability and xhtml compliance are not really taken in account, or is it and i missed a point somewhere?) What do you mean exactly by usability not being taken into account ? It's not a very useful comment without further explanation of where you find usability lacking. As for xhtml, the default Jetspeed distribution is not XHTML compliant but the engine is completely ready to support, somebody just has to define xhtml complaint templates. Any contribution in this respect is evry welcome :) -- Raphaël Luta - [EMAIL PROTECTED] 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE : JSR-168 Article Part 1 in JavaWorld
Sorry, I´ve forgot to say that this version of the PDK is only running with IE, but the release 6.0 of SAP Enterprise Portal should be browser independent (I´ve heard). Unfortunetly there is no PDK available yet. I didn´t want you to switch from Jetspeed to SAP EP neither did I want to leave the impession that this product is the best Portal at all. It has it´s drawbacks like any other products but it´s worth a look especially because of it´s client side capabilities. Can´t be bad to have a look at products from competitors, can it!? Helmut Gregory Joseph schrieb: Raphaël Luta wrote: I just registered to check it out and, of course, it simply doesn't recognize my Mozilla Firebird as a supported client so I get a very ugly site. Thanks for reminding me why I so dislike client-side technologies :) Same with Mozilla1.4 (even without taking the pain to register) Ah, at least I'm glad I finally see a mail here from someone that seems to be *against* iframes ;) (i was evaluating jetspeed, and it seems usability and xhtml compliance are not really taken in account, or is it and i missed a point somewhere?) g - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE : JSR-168 Article Part 1 in JavaWorld
De : Helmut Tammen [mailto:[EMAIL PROTECTED] Sorry, I´ve forgot to say that this version of the PDK is only running with IE, but the release 6.0 of SAP Enterprise Portal should be browser independent (I´ve heard). Unfortunetly there is no PDK available yet. I didn´t want you to switch from Jetspeed to SAP EP neither did I want to leave the impession that this product is the best Portal at all. It has it´s drawbacks like any other products but it´s worth a look especially because of it´s client side capabilities. Can´t be bad to have a look at products from competitors, can it!? I can't agree more but I'm still rather unconvinced by portal solutions relying heavily on advanced client-side behavior whatever their benefits are in terms of GUI: too complex to properly develop in a portable way because the meaningful standards aren't properly implemented by all vendors and you have too high a risk of hitting costly C/S type deployment issues and tying your desktop solutions to your server solutions. Of course, your mileage may vary :) -- Raphaël Luta - [EMAIL PROTECTED] 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE : RE : JSR-168 Article Part 1 in JavaWorld
What do you mean exactly by usability not being taken into account ? It's not a very useful comment without further explanation of where you find usability lacking. maybe i should have used the word accessibility, in fact. (using html4 being a lack in this case) iframes lack accessibility in that less-capable users will have more trouble using/reading/earing them than a plain regular page, and a bit of usability in that the content is more likely to be wrongly indexed by web-search-engines, for example. But now, i must admit I did not verify these things I say with Iframes, only with frames. I'm just guessing/supposing actually. But it's just I was sorta scared reading everybody getting crazy about having each portlet in a iframe etc... (and i didn't mean to say all that about the whole jetspeed, but just about iframe usage and non-xhtml compliance) As for xhtml, the default Jetspeed distribution is not XHTML compliant but the engine is completely ready to support, somebody just has to define xhtml complaint templates. Any contribution in this respect is evry welcome :) well, if i end up using jetspeed, i hopefully will get some time to do this ;) g - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE : JSR-168 Article Part 1 in JavaWorld
Raphael, I know you're unconvinced by any of the client-side technology arguments. But I will say that you should consider that the history of java is replete with examples of users rejecting one-size fits all solutions. They were many great one size fits all technologies that users did not embrace because they demanded a richer experience. Technologies such as applets, AWT, Swing. The portal and portlet specification shouldn't become a one size fits all solution set. It needs to recognize and specify how users can utilize portlets in both a server-centric manner and a client-centric manner. From the iView site: For example, to monitor market data from Bloomberg.com, you can use an iView to add a Bloomberg window to your desktop, for a continuous, real-time display. You can click the window any time to access the full Bloomberg Web site. ... Other enterprise portals provide static views of data sources, or make you drill down into data sources one at a time. But with iViews, your personalized portal is an always-on, always-active link to all the applications you need. This perfectly represents the kind of interaction that I was referring to with the video portlet example that I used. Some portlets will need to be capable of being always on, always connected. And video isn't the only example. There are many others uses of real-time live-display data that will require this type of capability. This means not destroying the DOM with continual page reloads as is the case with Jetspeed today and the JSR-168 portlet spec needs to recognize these use cases provide for there existence both in the way the spec is written and in the reference implementation. rgds, Gerry Reno --- Luta, Raphael (VUN) [EMAIL PROTECTED] wrote: De : Helmut Tammen [mailto:[EMAIL PROTECTED] Sorry, I´ve forgot to say that this version of the PDK is only running with IE, but the release 6.0 of SAP Enterprise Portal should be browser independent (I´ve heard). Unfortunetly there is no PDK available yet. I didn´t want you to switch from Jetspeed to SAP EP neither did I want to leave the impession that this product is the best Portal at all. It has it´s drawbacks like any other products but it´s worth a look especially because of it´s client side capabilities. Can´t be bad to have a look at products from competitors, can it!? I can't agree more but I'm still rather unconvinced by portal solutions relying heavily on advanced client-side behavior whatever their benefits are in terms of GUI: too complex to properly develop in a portable way because the meaningful standards aren't properly implemented by all vendors and you have too high a risk of hitting costly C/S type deployment issues and tying your desktop solutions to your server solutions. Of course, your mileage may vary :) -- Raphaël Luta - [EMAIL PROTECTED] 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE : JSR-168 Article Part 1 in JavaWorld
Raphael, I know you're unconvinced by any of the client-side technology arguments. But I will say that you should consider that the history of java is replete with examples of users rejecting one-size fits all solutions. They were many great one size fits all technologies that users did not embrace because they demanded a richer experience. Technologies such as applets, AWT, Swing. The portal and portlet specification shouldn't become a one size fits all solution set. It needs to recognize and specify how users can utilize portlets in both a server-centric manner and a client-centric manner. From the iView site: For example, to monitor market data from Bloomberg.com, you can use an iView to add a Bloomberg window to your desktop, for a continuous, real-time display. You can click the window any time to access the full Bloomberg Web site. ... Other enterprise portals provide static views of data sources, or make you drill down into data sources one at a time. But with iViews, your personalized portal is an always-on, always-active link to all the applications you need. This perfectly represents the kind of interaction that I was referring to with the video portlet example that I used. Some portlets will need to be capable of being always on, always connected. And video isn't the only example. There are many others uses of real-time live-display data that will require this type of capability. This means not destroying the DOM with continual page reloads as is the case with Jetspeed today and the JSR-168 portlet spec needs to recognize these use cases provide for there existence both in the way the spec is written and in the reference implementation. rgds, Gerry Reno --- Luta, Raphael (VUN) [EMAIL PROTECTED] wrote: De : Helmut Tammen [mailto:[EMAIL PROTECTED] Sorry, I´ve forgot to say that this version of the PDK is only running with IE, but the release 6.0 of SAP Enterprise Portal should be browser independent (I´ve heard). Unfortunetly there is no PDK available yet. I didn´t want you to switch from Jetspeed to SAP EP neither did I want to leave the impession that this product is the best Portal at all. It has it´s drawbacks like any other products but it´s worth a look especially because of it´s client side capabilities. Can´t be bad to have a look at products from competitors, can it!? I can't agree more but I'm still rather unconvinced by portal solutions relying heavily on advanced client-side behavior whatever their benefits are in terms of GUI: too complex to properly develop in a portable way because the meaningful standards aren't properly implemented by all vendors and you have too high a risk of hitting costly C/S type deployment issues and tying your desktop solutions to your server solutions. Of course, your mileage may vary :) -- Raphaël Luta - [EMAIL PROTECTED] 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
Hi, I came a little bit late to this discussion. You should have had a look at the SAP Enterprise Portal (http://www.iviewstudio.com). They already extensively work with iFrames. Each portlet (they call them iViews) is enclosed in an iFrame. And furthermore they have sophisticated client side features like client-side eventing to send messages from one portlet (iView) to another and the client data-bag to exchange data from one portlet to another. With client-side eventing a portlet (in an iFrame) for example can send a request (data from a form) to the server and then inform another portlet (in another iFrame) that it should update itself because the data at the server has changed. The data-bag for example can be used to fill the fields of a form in portlet 1 upon a selection in portlet 2. Another feature is the possibility to store the state of a portlet at the client and restore it later. This can be used if the user filled a lot of data into a form, then quickly goes to another portal page without sending the form data to the server (for example to look at his mailbox) and afterwards returns to the portlet with the form. After returning to this portlet all the data is still available. I haven´t worked with this feature yet but I was told that it´s possible. These features together with the server-side framework make it possible to build complex portal applications with portlets that interact with each other. If you are interested in it you can download the PDK (Portal Development Kit) from http://www.iviewstudio.com. The PDK is a small version of the Enterpise Portal which can be installed within tomcat. It encloses a lot of examples an more detailed documentation of the mentioned features. Unfortunatly it´s not Open Source. When I switched to Jetspeed (because it is OSS) I missed these features. regards Helmut - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
At 08:32 AM 8/6/2003 -0700, you wrote: Hi Raphael, --- Luta, Raphael (VUN) [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
-trying to tie this linkage back to the original thread - De : Gerry Reno [mailto:[EMAIL PROTECTED] Hi Raphael, --- Luta, Raphael (VUN) [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
Hi Raphael, --- Luta, Raphael (VUN) [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSR-168 Article Part 1 in JavaWorld
Hi Scott, --- Weaver, Scott [EMAIL PROTECTED] wrote: Ok, but I still think that an optional Refresh button makes sense in some instances. Especially if you've set the TTL out very far and you then decide you want to refresh the portlet without refreshing the whole page. Of course, and that would be up to the portlet developer to provide that sort of functionality within his/her portlets. I'm assuming that there would be an 'API' so that the developer would know how to talk to the proxy and request their portlet refresh. rgds, Gerry Reno snip/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JSR-168 Article Part 1 in JavaWorld
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-userm=105850057414235w=2 http://marc.theaimsgroup.com/?l=jetspeed-userm=105846310309122w=2 Unfortunately there appears to be no latitude in the spec. The JSR-168 spec is supposed to permit creation of Enterprise Information Portals (EIP) using standardized portlets that are portable. This is good. But, I think that a lot of people have got themselves so caught up in the portlet lifecycle and the API and the storing of persistent portlet data and how do I create a __ type portlet and all the rest that they are failing to look at a bigger picture of some of the human-factors and user-experience perspectives and expectations with regard to web enterprise information portals. From my perspective this is very important since JSR-168 is going to be declared *the* standard. The standard should provide enough flexibility to accomodate all the common types of paradigms and technologies to which users have come to use when utilizing the Web. The portlet spec as currently written is analogous to having a number of browsers open on your desktop and each one would represent a portlet and if you were to hit the reload button or minimize or maximize or submit a form from any of them, then all of them would reload their pages. Well this works great if you don't mind losing any client-side processing that is going on. The problem is that users are accustomed to having client-side processing and in fact expect a consistent context when interacting with client-side technologies. As it stands now, the portlet spec is dictating that every portlet mode or window state change causes an action request to be sent to the server. If you understand how the browser and pages and the document object model and browser client-side technologies work you immediately realize that constantly reloading pages is not a good thing. Ok, let's look at a real simple example. A user is interacting with an information rich JSR-168 portal. In the portal there is a media player portlet that allows the user to select from a list of available videos to view and there are other portlets on the page for various other information purposes. While the user is viewing a video presentation, one of these other portlets is doing something distracting and the user would like to minimize it so that the user can concentrate on the video presentation. Under the current JSR-168 spec the user's action to minimize this portlet results in a page request being sent back to the server which in turn results in the page being reloaded. What that does is destroy the original document object model (DOM) in the browser representing the original page and the subsequent creation of a new DOM representing the newly reloaded page. All running embedded client-side technologies such as applets, DHTML, javascript, Flash, SVG, etc. etc. are destroyed losing their contexts. The browser then redraws the reloaded page and all the portlets and initializes and starts all client-side scripts, modules, applets, objects, etc. once again. Well, for our user watching the video what happens is that the media player in the portlet is destroyed, recreated, initialized and starts over waiting for the user to make a video selection. Not exactly what the user would expect. Users are used to doing things like expanding and contracting lists, boxes and tables without seeing an expensive round trip to the server and a page reload. These are all things that are very easy to do on the client using DHTML, javascript, Flash, SVG or any other of the client-side technologies that can manipulate the DOM. In a broader perspective, under the current JSR-168 spec, all uses of client-side technologies are severely limited due to the interaction model dictated by the spec. Another issue is the user's perception of performance. I submit that a better model is one in which Java dovetails with client-side technologies to minimize round-trips to the server. Try testing a Jetspeed portal from a dial-up connection. If you are interacting with its portlets and using any of the buttons controlling portlet mode or window state, each button press results is a new page being served with the net experience being a portal that is painfully slow. What I notice a lot of the current Jetspeed sites doing is completely removing any of the portlet mode or window state buttons from the portlets and forcing the user into a rigid predetermined layout. This reduces the abilty of a user to cause a page reload but it defeats nearly all of the user preference flexibility of the portal. To create a portal model that will provide for a
Re: JSR-168 Article Part 1 in JavaWorld
Hi Scott, --- Weaver, Scott [EMAIL PROTECTED] wrote: Not exactly, the main user interface window would have in this model a single DOM with no IFRAME (ie true content aggregation), the hidden iFrame being used as a backround content cache to be used by the main window to load content. And act as the physical requestor back to the server. But yes, Raphael, this is exactly what I was getting at, using a single, hidden IFRAME, not an IFRAME for each portlet's content. Can you please clarify how this operates. Are you envisioning a proxy requestor that will allow the main page DOM to remain intact. If so, then this may work. If not, then it definitely would not work. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
Hi Scott, --- Weaver, Scott [EMAIL PROTECTED] wrote: If we used client-side operations to alter window state, how would we maintain/persist a user's window state when that user closes their browser? What if a user logs in from a different browser on a different machine, wouldn't they expect the state of there portlets to be same no matter where they are accessing the portal from? Ok, what I think is necessary is the notion of a client=side controller that would notify the server-side of the window states that were being set on the client rather than constantly reloading pages all the time. The immediate model that comes to mind is the one of using iframes for each portlet where you can declare some of these portlets at 'persistent' like a media player portlet and the controller would tell the other 'non-persistent' portlet iframes to 'reload' on certain events. This way the entire page is not reloading and destroying client-side technology contexts. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : JSR-168 Article Part 1 in JavaWorld
De : Gerry Reno [mailto:[EMAIL PROTECTED] 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-userm=105850057414235w=2 http://marc.theaimsgroup.com/?l=jetspeed-userm=105846310309122w=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 - [EMAIL PROTECTED] 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSR-168 Article Part 1 in JavaWorld
Hi Scott, --- Weaver, Scott [EMAIL PROTECTED] wrote: The one thing we have to remember is that portlet content, i.e. stock quotes, weather, etc should be provided in real-time and as such, the content of these will need to be updated periodically. What I am getting at is that if the user only is changing window state we rarely get a chance to get back to the server to update all of the portlets' content on the page. I think this is the reasoning my statement below. We still need to observe the contract that every page request invokes each visible portlet's render method whether the request be a render request or an action request. The key word is *visible* portlet. The loophole in this is the fact that cached portlets' render method invocation can be skipped during the render/request phase. Look between lines 15 - 30 in the spec. Even with this requirement, the main page could still stay intact as all requests go through the proxy, however we may have to rewrite the DOM of multiple portlets due to the above issues. I don't see that as a problem. Rewriting the DOM itself is nearly instantaneous from the perspective of the user. I see this happening only for *volatile* portlets that much touch the server regularly. I think that I would prefer though that such portlets have their own Refresh button for obtaining updated content rather than always hitting the server on every request. rgds, Gerry Regards, *===* * Scott T Weaver* * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Gerry Reno [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 3:18 PM To: Jetspeed Users List Subject: Re: JSR-168 Article Part 1 in JavaWorld Hi Scott, Yes, this type of model shows some promise. Now, what is also important to recognize is that by manipulating the DOM on a maximize, that all the portlets are actually still present. Just not visible. So perhaps we would need to send a message to non-visible portlets so that they could perhaps 'pause' when they weren't visible. rgds, Gerry Reno --- Weaver, Scott [EMAIL PROTECTED] wrote: Can you please clarify how this operates. Are you envisioning a proxy requestor that will allow the main page DOM to remain intact. If so, then this may work. If not, then it definitely would not work. Yes the main page stays intact and all portlet url's targets would be the IFRAME proxy. I have not put a lot of thought into the specifics, so that is open to discussion. Obviously, the proxy IFRAME will have to do A LOT of DOM manipulation in the main page. Here is a simple scenario: My apologies if the diagram gets out of whack ;) User click Maximize on a portlet | -- This request is sent to the proxy IFRAME | | (The proxy IFRAME then checks if DOM Manipulation required?) || truefalse || The DOM is re-written to Nothing is done to the DOM facilitate the new window | state.| | | | | - | | The request is now sent back to the server to fulfill the JSR-168 requirements | Does the request response require a change In the target portlets content? | - | | true false | | re-write the DOMNothing is done to the DOM accordingly This is a very high level model of what I envision, it is by no means complete. *===* * Scott T Weaver* * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Gerry Reno [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 1:02 PM To: Jetspeed Users List Subject: Re: JSR-168 Article Part 1 in JavaWorld Hi Scott, --- Weaver, Scott [EMAIL PROTECTED] wrote: Not exactly, the main user interface window would have in this model a single DOM with no IFRAME (ie true content aggregation), the hidden iFrame being used as a backround content cache to be used
Re: JSR-168 Article Part 1 in JavaWorld
Hi Scott, Yes, this type of model shows some promise. Now, what is also important to recognize is that by manipulating the DOM on a maximize, that all the portlets are actually still present. Just not visible. So perhaps we would need to send a message to non-visible portlets so that they could perhaps 'pause' when they weren't visible. rgds, Gerry Reno --- Weaver, Scott [EMAIL PROTECTED] wrote: Can you please clarify how this operates. Are you envisioning a proxy requestor that will allow the main page DOM to remain intact. If so, then this may work. If not, then it definitely would not work. Yes the main page stays intact and all portlet url's targets would be the IFRAME proxy. I have not put a lot of thought into the specifics, so that is open to discussion. Obviously, the proxy IFRAME will have to do A LOT of DOM manipulation in the main page. Here is a simple scenario: My apologies if the diagram gets out of whack ;) User click Maximize on a portlet | -- This request is sent to the proxy IFRAME | | (The proxy IFRAME then checks if DOM Manipulation required?) || truefalse || The DOM is re-written to Nothing is done to the DOM facilitate the new window | state.| | | | | - | | The request is now sent back to the server to fulfill the JSR-168 requirements | Does the request response require a change In the target portlets content? | - | | true false | | re-write the DOMNothing is done to the DOM accordingly This is a very high level model of what I envision, it is by no means complete. *===* * Scott T Weaver* * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Gerry Reno [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 1:02 PM To: Jetspeed Users List Subject: Re: JSR-168 Article Part 1 in JavaWorld Hi Scott, --- Weaver, Scott [EMAIL PROTECTED] wrote: Not exactly, the main user interface window would have in this model a single DOM with no IFRAME (ie true content aggregation), the hidden iFrame being used as a backround content cache to be used by the main window to load content. And act as the physical requestor back to the server. But yes, Raphael, this is exactly what I was getting at, using a single, hidden IFRAME, not an IFRAME for each portlet's content. Can you please clarify how this operates. Are you envisioning a proxy requestor that will allow the main page DOM to remain intact. If so, then this may work. If not, then it definitely would not work. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
On Tuesday, August 5, 2003, at 06:47 PM, Gerry Reno wrote: From my perspective this is very important since JSR-168 is going to be declared *the* standard. The standard should provide enough flexibility to accomodate all the common types of paradigms and technologies to which users have come to use when utilizing the Web. The portlet spec as currently written is analogous to having a number of browsers open on your desktop and each one would represent a portlet and if you were to hit the reload button or minimize or maximize or submit a form from any of them, then all of them would reload their pages. Well this works great if you don't mind losing any client-side processing that is going on. The problem is that users are accustomed to having client-side processing and in fact expect a consistent context when interacting with client-side technologies. As it stands now, the portlet spec is dictating that every portlet mode or window state change causes an action request to be sent to the server. If you understand how the browser and pages and the document object model and browser client-side technologies work you immediately realize that constantly reloading pages is not a good thing. With the portlet api, you are free to handle client-side programming, inside the scripts and content generated by your portlet. However portal-level events such as minimize and maximize, or a portlet action, must be passed back to the portal so that the targeted portlet is notified of the event. Portlets, like servlets, are server-side objects and that is what the Java specification focuses on. Im thinking about your maximize example. Wouldn't most cases require different or more content in maximized mode, requiring a trip back to the server? Same for print friendly mode. Your point about reloading and losing state of the other portlets is well taken. Even IFrame portlets require state management and rewriting. I try to steer clear of applets when working with portlets. I do think these issues need to be addressed in future versions of the spec. You also spoke about when a form is submitted from within an IFrame. In Jetspeed today, we are capable of returning only the content of the particular portlet back to the IFrame. The Portlet API is restrictive here, requiring that all portlets return content per request Jetspeed could add an extended mode to support this, but then your portlet may not be portable. I'd like to say that in general I agree with what you are saying regarding the user experience problems with portlets and constantly reloading everything. Im still trying to figure out if its really applicable to a Java Portlet specification. My gut feeling is that it should be, Im just not sure how yet. -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] +01 707 773-4646 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : JSR-168 Article Part 1 in JavaWorld
De : Gerry Reno [mailto:[EMAIL PROTECTED] Erik, Serge (I'm going to respond to both of you here) snip answe from Serge I think that this spec needs to recognize that in order for a portal to be able to preserve the context for client-side technologies, which by definition means that you must maintain the integrity of the main page DOM, that it cannot have every portlet action reloading the main page. snip iFrame based model description Gerry, I think we have all understood your issue and proposed solution now, so you don't *need* to re-include your proposed model in every message you send, that will shorten your mails and make them easier to read to to reply to. I'll try summarize what has been said so far (I hope I will not miss a major point somewhere) : A1. you advocate the need for a strong support of client side technologies in the JSR 168 portal specificcation A2 you propose a portal implementation model based around portlet content included in IFrame tags and a persistent client-side controller in the main page. A3 Scott has proposed an alternate implementation model for the client side based around a reqsuest proxy to a hidden iFrame that is manipulated by the main window, which is interacting with the user A4 Erik has stated that he needs to be convinced that advanced client-side technologies as a viable market right now due to lack of standard support in IE which has a commanding share of the browser market. A5 Serge has stated that the current JSR 168 spec does allow portlet developers to take advantage a client-side technologies if they wish but it's a good thing that it does not require them to do so. A6 Several people have expressed the importance of supporting light clients (like CHTML, WML, etc...) with the spec. A7 Serge and myself have pointed out that WSRP would allow you to invoke a server based portlet and completely control the aggregation on the client. About A2, I must point out that in this setup *no* real output aggregation actually occurs since iFrames are really independant documents based on independant HTTP requests. I find this setup - limiting cross-portlet communication (like you can't use request attributes to pass information around between portlets on the same page) and portal-portlet communication (how to you refresh a page navigation title based on a portlet content change if you don't reload the page ?) - mush less efficient in terms of network and processing power for information oriented portals (like Yahoo), where probably 90% of the requests are read the page/update the page. In these scenarios the client-side code to download, the multiple request to process and possibly the larger amount of content you send out initially to the client to allow it to handle the minimize/maximize features without portal callback quickly add up to reduce the overall performance - difficult to implement for public sites where validating rich client-side portal features against many client configurations is a costly proposition. - not necessarily extremely user friendly given the nature of IFRAME rendering, for example implementing a complete *printable* portal page around IFRAMEs, one that never truncates content, looks like a real challenge for me. Based on the above, I personnally tend to agree with Erik to A4 and with Serge would that JSR 168 has set out to standardize a portlet specification within a server-controlled aggregation process and has done a pretty good job of it, without imposing too many constraints on the developers although it *does* feel like they settled for the minimum common denominator this time around and that they could have gone further on some points. Since what you really call for is a client-controlled aggregation, I can only reiterate that you look closely at WSRP which will allow you to implement exactly any behavior you like while still leveraging JSR 168 compliant portal through a WSRP connector. -- Raphaël Luta - [EMAIL PROTECTED] 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
Re: JSR-168 Article Part 1 in JavaWorld
Raphael, De : Gerry Reno [mailto:[EMAIL PROTECTED] Erik, Serge (I'm going to respond to both of you here) snip answe from Serge I think that this spec needs to recognize that in order for a portal to be able to preserve the context for client-side technologies, which by definition means that you must maintain the integrity of the main page DOM, that it cannot have every portlet action reloading the main page. snip iFrame based model description snip/ I'll try summarize what has been said so far (I hope I will not miss a major point somewhere) : A1. you advocate the need for a strong support of client side technologies in the JSR 168 portal specificcation Correct. A2 you propose a portal implementation model based around portlet content included in IFrame tags and a persistent client-side controller in the main page. Yes. A3 Scott has proposed an alternate implementation model for the client side based around a reqsuest proxy to a hidden iFrame that is manipulated by the main window, which is interacting with the user. I took this as essentially the same type of solution as A2. A4 Erik has stated that he needs to be convinced that advanced client-side technologies as a viable market right now due to lack of standard support in IE which has a commanding share of the browser market. The minor issues with IE are well-known and can easily be worked around. A5 Serge has stated that the current JSR 168 spec does allow portlet developers to take advantage a client-side technologies if they wish but it's a good thing that it does not require them to do so. Well, only if the developer writes all the aggregation code and puts in place all the necessary communication and window control mechanisms. Not exactly the way to insure a portable standardized approach. There would need to be a standard model developed and an implementation that demonstrated the ability of this approach to work in all scenarios. This is the type of thing that I'm looking for the spec to provide. A6 Several people have expressed the importance of supporting light clients (like CHTML, WML, etc...) with the spec. Agreed. I don't see the two goals as conflicting. A7 Serge and myself have pointed out that WSRP would allow you to invoke a server based portlet and completely control the aggregation on the client. see A5 comment. About A2, I must point out that in this setup *no* real output aggregation actually occurs since iFrames are really independant documents based on independant HTTP requests. I find this setup - limiting cross-portlet communication (like you can't use request attributes to pass information around between portlets on the same page) and portal-portlet communication (how to you refresh a page navigation title based on a portlet content change if you don't reload the page ?) Is main page request attributes the only way that inter-portlet communication can take place? I would hope not. - mush less efficient in terms of network and processing power for information oriented portals (like Yahoo), where probably 90% of the requests are read the page/update the page. In these scenarios the client-side code to download, the multiple request to process and possibly the larger amount of content you send out initially to the client to allow it to handle the minimize/maximize features without portal callback quickly add up to reduce the overall performance I really disagree with this assessment. Yes, you are making more requests but these requests are each much smaller. As far as sending the data for a minimize/maximize without callback, as I stated, you load the normalize view in the foreground and you load the maximize view in the background and the user will not experience any difference in performance. - difficult to implement for public sites where validating rich client-side portal features against many client configurations is a costly proposition. We all do this today. It's not a big deal. - not necessarily extremely user friendly given the nature of IFRAME rendering, for example implementing a complete *printable* portal page around IFRAMEs, one that never truncates content, looks like a real challenge for me. I don't think that most people are going to want to print the portal page. What they want is to be able to print the 'portlet' page. This is a simple manipulation of CSS attribute in the DOM. Based on the above, I personnally tend to agree with Erik to A4 and with Serge would that JSR 168 has set out to standardize a portlet specification within a server-controlled aggregation process and has done a pretty good job of it, without imposing too many constraints on the developers although it *does* feel like they settled for the minimum common denominator this time around and that they could have gone further on some points. Since what you really call for is a
RE: JSR-168 Article Part 1 in JavaWorld
I see the refresh option as porlet mode/render request, more than likely the doView() mode. *===* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Weaver, Scott [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 4:29 PM To: 'Jetspeed Users List' Subject: RE: JSR-168 Article Part 1 in JavaWorld I'm assuming that there would be an 'API' so that the developer would know how to talk to the proxy and request their portlet refresh. Developers should not need to be aware of this. We would have configuration options that would generate URLs that would be aware of this and possibly use javascript to intercept these requests and send them to the proxy. Like I said I don't have all the technical details figured out. We need to hide as much of the implementation as possible from the developer so their portlets can be used in portals that support JSR-168 but do not support the extended DOM interaction model you are proposing. Regards, *===* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Gerry Reno [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 4:11 PM To: Jetspeed Users List Subject: RE: JSR-168 Article Part 1 in JavaWorld Hi Scott, --- Weaver, Scott [EMAIL PROTECTED] wrote: Ok, but I still think that an optional Refresh button makes sense in some instances. Especially if you've set the TTL out very far and you then decide you want to refresh the portlet without refreshing the whole page. Of course, and that would be up to the portlet developer to provide that sort of functionality within his/her portlets. I'm assuming that there would be an 'API' so that the developer would know how to talk to the proxy and request their portlet refresh. rgds, Gerry Reno snip/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSR-168 Article Part 1 in JavaWorld
Hi Scott, --- Weaver, Scott [EMAIL PROTECTED] wrote: I don't see that as a problem. Rewriting the DOM itself is nearly instantaneous from the perspective of the user. I see this happening only for *volatile* portlets that much touch the server regularly. I think that I would prefer though that such portlets have their own Refresh button for obtaining updated content rather than always hitting the server on every request. I don't like the idea of the onus being on the user refresh their portlets manually, seems a bit kludgy to me. I think if we reverse this, and make it so that portlets that have extensive TTLs, i.e. they rarely or never need periodic updates use the caching attribute within their descriptors to effectively skip their ender phases and portlets like the stock quote, update their content with each request by using the proxy to do so. Now, we are adhering entirely to the spec by using the functionality provided there in to effectively slow/stop the render phase for a portlet unless specifically requested by giving a very long cache period. Ok, but I still think that an optional Refresh button makes sense in some instances. Especially if you've set the TTL out very far and you then decide you want to refresh the portlet without refreshing the whole page. rgds, Gerry Reno Regards, *===* * Scott T Weaver* * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Gerry Reno [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 3:46 PM To: Jetspeed Users List Subject: RE: JSR-168 Article Part 1 in JavaWorld Hi Scott, --- Weaver, Scott [EMAIL PROTECTED] wrote: The one thing we have to remember is that portlet content, i.e. stock quotes, weather, etc should be provided in real-time and as such, the content of these will need to be updated periodically. What I am getting at is that if the user only is changing window state we rarely get a chance to get back to the server to update all of the portlets' content on the page. I think this is the reasoning my statement below. We still need to observe the contract that every page request invokes each visible portlet's render method whether the request be a render request or an action request. The key word is *visible* portlet. The loophole in this is the fact that cached portlets' render method invocation can be skipped during the render/request phase. Look between lines 15 - 30 in the spec. Even with this requirement, the main page could still stay intact as all requests go through the proxy, however we may have to rewrite the DOM of multiple portlets due to the above issues. I don't see that as a problem. Rewriting the DOM itself is nearly instantaneous from the perspective of the user. I see this happening only for *volatile* portlets that much touch the server regularly. I think that I would prefer though that such portlets have their own Refresh button for obtaining updated content rather than always hitting the server on every request. rgds, Gerry Regards, *===* * Scott T Weaver* * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Gerry Reno [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 3:18 PM To: Jetspeed Users List Subject: Re: JSR-168 Article Part 1 in JavaWorld Hi Scott, Yes, this type of model shows some promise. Now, what is also important to recognize is that by manipulating the DOM on a maximize, that all the portlets are actually still present. Just not visible. So perhaps we would need to send a message to non-visible portlets so that they could perhaps 'pause' when they weren't visible. rgds, Gerry Reno --- Weaver, Scott [EMAIL PROTECTED] wrote: Can you please clarify how this operates. Are you envisioning a proxy requestor that will allow the main page DOM to remain intact. If so, then this may work. If not, then it definitely would not work. Yes the main page stays intact and all portlet url's targets would be the IFRAME proxy. I have not put a lot of thought into the specifics, so that is open to discussion. Obviously, the proxy IFRAME will have to do A LOT of DOM manipulation in the main page. Here is a simple scenario: My apologies if the diagram gets out of whack ;) User click Maximize on a portlet | -- This request is sent to the proxy IFRAME
Re: RE : JSR-168 Article Part 1 in JavaWorld
Hi Raphael, --- Luta, Raphael (VUN) [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
Hi David, On Tuesday, August 5, 2003, at 06:47 PM, Gerry Reno wrote: From my perspective this is very important since JSR-168 is going to be declared *the* standard. The standard should provide enough flexibility to accomodate all the common types of paradigms and technologies to which users have come to use when utilizing the Web. The portlet spec as currently written is analogous to having a number of browsers open on your desktop and each one would represent a portlet and if you were to hit the reload button or minimize or maximize or submit a form from any of them, then all of them would reload their pages. Well this works great if you don't mind losing any client-side processing that is going on. The problem is that users are accustomed to having client-side processing and in fact expect a consistent context when interacting with client-side technologies. As it stands now, the portlet spec is dictating that every portlet mode or window state change causes an action request to be sent to the server. If you understand how the browser and pages and the document object model and browser client-side technologies work you immediately realize that constantly reloading pages is not a good thing. --- David Sean Taylor [EMAIL PROTECTED] wrote: With the portlet api, you are free to handle client-side programming, inside the scripts and content generated by your portlet. However portal-level events such as minimize and maximize, or a portlet action, must be passed back to the portal so that the targeted portlet is notified of the event. Portlets, like servlets, are server-side objects and that is what the Java specification focuses on. Im thinking about your maximize example. Wouldn't most cases require different or more content in maximized mode, requiring a trip back to the server? Same for print friendly mode. This is what I am talking about when I refer to client-side technologies being severely restricted. Any client-side technologies are going to be limited by the fact that they will live only until the next button press on the portal and then they will be destroyed and recreated with the next page load. For client-side technologies it's as a famous catcher once said, It's deja-vu all over again. As far as the maximize example, if you remember from some of my other threads that what is expensive is server round-trips. My preference would be to see that all the content, both normalized and maximized markup is sent to the browser in the initial request and then window state changes only cause that content to be revealed or hidden as appropriate. The content for the normal display can be sent with the additional content for maximized view being loaded in the background so that there is no delay in the presentation of the portal page to the user. As far as print-friendly, you just go from a CSS attribute of 'media=screen' to 'media=print'. You can just manipulate the DOM to cause this to happen! You don't need to go to the server. Your point about reloading and losing state of the other portlets is well taken. Even IFrame portlets require state management and rewriting. I try to steer clear of applets when working with portlets. I do think these issues need to be addressed in future versions of the spec. The time to address these issues is now, not later. The basic model for portable portlets is being established right now. It isn't going to be possible to 'extend' this model later to accomodate the type of interaction that I'm proposing. The fundamental model needs to be established correctly, right now, in order to be able to extend it later. The reason that you are steering clear of good client-side technologies such as applets is because the current spec prevents you from using them in any meaningful way. You also spoke about when a form is submitted from within an IFrame. In Jetspeed today, we are capable of returning only the content of the particular portlet back to the IFrame. The Portlet API is restrictive here, requiring that all portlets return content per request Jetspeed could add an extended mode to support this, but then your portlet may not be portable. With the way in which the portlets operate currently, I'm finding myself driven towards doing everything inside IFrames with a reload button on them in order to be able to utilize anything with regard to client-side technologies. This has been my same experience with jsf. I find myself only using jsf inside of an iframe so as to be able to maintain the context of the main page and not have everything constantly reloading and destroying the client-side technology contexts. I'd like to say that in general I agree with what you are saying regarding the user experience problems with portlets and constantly reloading everything. Im still trying to figure out if its really applicable to a Java Portlet
Re: JSR-168 Article Part 1 in JavaWorld
Hi Scott, --- Weaver, Scott [EMAIL PROTECTED] wrote: Gerry, Here is how I envisioned it. You would have a Request Proxy probably a hidden IFrame that has the ability to write both to the client (DOM manipulation/screen repainting) and the server(record the user's current page and portlet state/process non trivial portlet requests). This is over-simplified but gives you an idea of how I think it could be implemented. The client-side portlet controller should exist in the main page not in it's own iframe. That would be destroyed anyway if the main page were reloaded. The key is that the portlets have to exist in a framework that allows them to be manipulated separately - the only construct that is currently capable of this in a browser is the iframe. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
At 14:44 06.08.2003 -0700, you wrote: The portlet spec is locking out client-side technologies!! If the arguments and points that I have presented have not convinced you then sobeit. I can pretty much guarantee you that going forward with the spec the way it is it will fail. Users are going to reject the slow performance the lack of being able to use good client-side technologies that other portal implementations are going to allow. The only way that I'll even consider designing anything around this current spec is to remove all of the portlet window state buttons and portlet mode buttons so that I can use some client-side technologies in the portal and the user won't be experiencing constant page reloading. Well the spec is actually very close to the Servlet API in some ways. The Servlet API is also quite minimal in it's coverage, and I wouldn't call it a failure despite the fact that it didn't cover areas such as : - browser capabilities - client-side supported technologies - file uploads etc... I do understand very well the point you are making. For example I personally prefer to use an email client such as Evolution or Eudora than using the web interface of Hotmail or Yahoo Mail. Why ? Because of all the server round trips that do make some operations tedious. But I also like to have my mail all in one place, and not have to login into seperate web interfaces to check my mail, which I guess brings my needs back to portal needs. But I fail to understand your point as to why the current spec is locking client-side technologies out. As I said previously I think the spec is lacking in the areas of specifying the lookup and dispatching technologies to portlets, but I think that can come in a later revision of the spec, or become a defacto standard through the promotion of technologies such as Pluto that are (will be actually) under a very free license such as Apache. I think the spec doesn't include client technology support as per say, but I wouldn't say it locks it out. If I take a quick look at what is needed using todays technologies in order to make the client-side experience nicer : - Javascript - DOM Level 2 - Probably LiveConnect if we want to interact with applets - A way to communicate on a portlet basis with the server, be it iFrame, or SOAP calls or something like that. On the server-side we need : - a SOAP server or an HTTP server that hooks up to the client - A collection of portlets Now what let's say that the portlets interact with the client through WSRP. Why couldn't the WSRP server communicate with it's portlets through the JSR-168 interfaces (which is exactly what Oracle's implementation does btw) ? It would then just be up to the implementation of the portlets to follow guidelines (which are NOT in the spec), to interface well with the client side controls. These guidelines might be what you think is lacking in the spec, but as I see it it is technologically possible to do this, although not as easy. The point I am mostly trying to make here is that the spec is aimed at defining how portlet developers should do their work in a broad and all-encompassing fashion. Constraining them too much will probably scare them away. Now they should ALSO have the possibility to write code without any client-side controls, and the spec allows this too. But I think that if there is some serious flaw in the spec that we have yet to uncover, either we must correct it now if still possible, or it will be corrected in a later update. Regards, Serge Huber. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
Hi Marc, --- Marc Tremblay [EMAIL PROTECTED] wrote: While I agree that allowing for the use of rich client side technologies is highly desirable, we need to remember that not all user agents will be able to support said technologies. I'm thinking specifically of the myriad of WML devices out there. Since this is an initial spec, I'm much happier that it is capable of working with user agents of limited ability than if such user agents were forgotten altogether or simply tacked on at the end. Let's get a foundation in place first, then we can tweak it. It reminds me of the EJB 1.0 spec whose greatest purpose, IMO, was to be the foundation for later revisions which were actually usable. -- Marc I just don't think that the current spec is going to be extendable. The fundamental model has to be right and I don't think that it is. As far as WML devices and as I said in a letter that I wrote to JSR-168 team, the small screen device technology is progressing at a very rapid pace and these devices will very shortly be capable of DOM processing. Check out all the buzz about SVG on small screen devices. I think the spec is placing way too much emphasis on the 'lowest common denominator' approach. Users, as the Java community knows all too well, tend to reject these types of approaches. Look at AWT, Swing, applets. They were to be the killer technologies and users didn't embrace them en-masse because they wanted a richer experience. My feeling is that the portlet spec is making the same type of mistake here. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSR-168 Article Part 1 in JavaWorld
Gerry, Here is how I envisioned it. You would have a Request Proxy probably a hidden IFrame that has the ability to write both to the client (DOM manipulation/screen repainting) and the server(record the user's current page and portlet state/process non trivial portlet requests). This is over-simplified but gives you an idea of how I think it could be implemented. *===* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Gerry Reno [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 12:21 PM To: Jetspeed Users List Subject: Re: JSR-168 Article Part 1 in JavaWorld Hi Scott, --- Weaver, Scott [EMAIL PROTECTED] wrote: If we used client-side operations to alter window state, how would we maintain/persist a user's window state when that user closes their browser? What if a user logs in from a different browser on a different machine, wouldn't they expect the state of there portlets to be same no matter where they are accessing the portal from? Ok, what I think is necessary is the notion of a client=side controller that would notify the server-side of the window states that were being set on the client rather than constantly reloading pages all the time. The immediate model that comes to mind is the one of using iframes for each portlet where you can declare some of these portlets at 'persistent' like a media player portlet and the controller would tell the other 'non-persistent' portlet iframes to 'reload' on certain events. This way the entire page is not reloading and destroying client-side technology contexts. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSR-168 Article Part 1 in JavaWorld
I don't see that as a problem. Rewriting the DOM itself is nearly instantaneous from the perspective of the user. I see this happening only for *volatile* portlets that much touch the server regularly. I think that I would prefer though that such portlets have their own Refresh button for obtaining updated content rather than always hitting the server on every request. I don't like the idea of the onus being on the user refresh their portlets manually, seems a bit kludgy to me. I think if we reverse this, and make it so that portlets that have extensive TTLs, i.e. they rarely or never need periodic updates use the caching attribute within their descriptors to effectively skip their ender phases and portlets like the stock quote, update their content with each request by using the proxy to do so. Now, we are adhering entirely to the spec by using the functionality provided there in to effectively slow/stop the render phase for a portlet unless specifically requested by giving a very long cache period. Regards, *===* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Gerry Reno [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 3:46 PM To: Jetspeed Users List Subject: RE: JSR-168 Article Part 1 in JavaWorld Hi Scott, --- Weaver, Scott [EMAIL PROTECTED] wrote: The one thing we have to remember is that portlet content, i.e. stock quotes, weather, etc should be provided in real-time and as such, the content of these will need to be updated periodically. What I am getting at is that if the user only is changing window state we rarely get a chance to get back to the server to update all of the portlets' content on the page. I think this is the reasoning my statement below. We still need to observe the contract that every page request invokes each visible portlet's render method whether the request be a render request or an action request. The key word is *visible* portlet. The loophole in this is the fact that cached portlets' render method invocation can be skipped during the render/request phase. Look between lines 15 - 30 in the spec. Even with this requirement, the main page could still stay intact as all requests go through the proxy, however we may have to rewrite the DOM of multiple portlets due to the above issues. I don't see that as a problem. Rewriting the DOM itself is nearly instantaneous from the perspective of the user. I see this happening only for *volatile* portlets that much touch the server regularly. I think that I would prefer though that such portlets have their own Refresh button for obtaining updated content rather than always hitting the server on every request. rgds, Gerry Regards, *===* * Scott T Weaver* * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Gerry Reno [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 3:18 PM To: Jetspeed Users List Subject: Re: JSR-168 Article Part 1 in JavaWorld Hi Scott, Yes, this type of model shows some promise. Now, what is also important to recognize is that by manipulating the DOM on a maximize, that all the portlets are actually still present. Just not visible. So perhaps we would need to send a message to non-visible portlets so that they could perhaps 'pause' when they weren't visible. rgds, Gerry Reno --- Weaver, Scott [EMAIL PROTECTED] wrote: Can you please clarify how this operates. Are you envisioning a proxy requestor that will allow the main page DOM to remain intact. If so, then this may work. If not, then it definitely would not work. Yes the main page stays intact and all portlet url's targets would be the IFRAME proxy. I have not put a lot of thought into the specifics, so that is open to discussion. Obviously, the proxy IFRAME will have to do A LOT of DOM manipulation in the main page. Here is a simple scenario: My apologies if the diagram gets out of whack ;) User click Maximize on a portlet | -- This request is sent to the proxy IFRAME | | (The proxy IFRAME then checks if DOM Manipulation required?) || truefalse || The DOM is re-written to Nothing is done to the DOM facilitate the new window | state
RE: JSR-168 Article Part 1 in JavaWorld
Hi Scott, --- Weaver, Scott [EMAIL PROTECTED] wrote: I'm assuming that there would be an 'API' so that the developer would know how to talk to the proxy and request their portlet refresh. Developers should not need to be aware of this. We would have configuration options that would generate URLs that would be aware of this and possibly use javascript to intercept these requests and send them to the proxy. Like I said I don't have all the technical details figured out. We need to hide as much of the implementation as possible from the developer so their portlets can be used in portals that support JSR-168 but do not support the extended DOM interaction model you are proposing. Something like a Refresh button would be optional and would need to be examined as to whether it could be applied to both models. Ok, I understand. You need to think about it some more for further details to emerge. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
While I agree that allowing for the use of rich client side technologies is highly desirable, we need to remember that not all user agents will be able to support said technologies. I'm thinking specifically of the myriad of WML devices out there. Since this is an initial spec, I'm much happier that it is capable of working with user agents of limited ability than if such user agents were forgotten altogether or simply tacked on at the end. Let's get a foundation in place first, then we can tweak it. It reminds me of the EJB 1.0 spec whose greatest purpose, IMO, was to be the foundation for later revisions which were actually usable. -- Marc On Tue, 2003-08-05 at 19:47, Gerry Reno wrote: 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-userm=105850057414235w=2 http://marc.theaimsgroup.com/?l=jetspeed-userm=105846310309122w=2 Unfortunately there appears to be no latitude in the spec. The JSR-168 spec is supposed to permit creation of Enterprise Information Portals (EIP) using standardized portlets that are portable. This is good. But, I think that a lot of people have got themselves so caught up in the portlet lifecycle and the API and the storing of persistent portlet data and how do I create a __ type portlet and all the rest that they are failing to look at a bigger picture of some of the human-factors and user-experience perspectives and expectations with regard to web enterprise information portals. From my perspective this is very important since JSR-168 is going to be declared *the* standard. The standard should provide enough flexibility to accomodate all the common types of paradigms and technologies to which users have come to use when utilizing the Web. The portlet spec as currently written is analogous to having a number of browsers open on your desktop and each one would represent a portlet and if you were to hit the reload button or minimize or maximize or submit a form from any of them, then all of them would reload their pages. Well this works great if you don't mind losing any client-side processing that is going on. The problem is that users are accustomed to having client-side processing and in fact expect a consistent context when interacting with client-side technologies. As it stands now, the portlet spec is dictating that every portlet mode or window state change causes an action request to be sent to the server. If you understand how the browser and pages and the document object model and browser client-side technologies work you immediately realize that constantly reloading pages is not a good thing. Ok, let's look at a real simple example. A user is interacting with an information rich JSR-168 portal. In the portal there is a media player portlet that allows the user to select from a list of available videos to view and there are other portlets on the page for various other information purposes. While the user is viewing a video presentation, one of these other portlets is doing something distracting and the user would like to minimize it so that the user can concentrate on the video presentation. Under the current JSR-168 spec the user's action to minimize this portlet results in a page request being sent back to the server which in turn results in the page being reloaded. What that does is destroy the original document object model (DOM) in the browser representing the original page and the subsequent creation of a new DOM representing the newly reloaded page. All running embedded client-side technologies such as applets, DHTML, javascript, Flash, SVG, etc. etc. are destroyed losing their contexts. The browser then redraws the reloaded page and all the portlets and initializes and starts all client-side scripts, modules, applets, objects, etc. once again. Well, for our user watching the video what happens is that the media player in the portlet is destroyed, recreated, initialized and starts over waiting for the user to make a video selection. Not exactly what the user would expect. Users are used to doing things like expanding and contracting lists, boxes and tables without seeing an expensive round trip to the server and a page reload. These are all things that are very easy to do on the client using DHTML, javascript, Flash, SVG or any other of the client-side technologies that can manipulate the DOM. In a broader perspective, under the current JSR-168 spec, all uses of client-side technologies are severely limited due to the interaction model dictated by the spec. Another issue is the user's perception of performance. I submit that a better model is
RE : RE : JSR-168 Article Part 1 in JavaWorld
De : Gerry Reno [mailto:[EMAIL PROTECTED] Hi Raphael, --- Luta, Raphael (VUN) [EMAIL PROTECTED] 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. -- Raphaël Luta - [EMAIL PROTECTED] 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : JSR-168 Article Part 1 in JavaWorld
De : Gerry Reno [mailto:[EMAIL PROTECTED] snip/ I'll try summarize what has been said so far (I hope I will not miss a major point somewhere) : A1. you advocate the need for a strong support of client side technologies in the JSR 168 portal specificcation Correct. A2 you propose a portal implementation model based around portlet content included in IFrame tags and a persistent client-side controller in the main page. Yes. A3 Scott has proposed an alternate implementation model for the client side based around a reqsuest proxy to a hidden iFrame that is manipulated by the main window, which is interacting with the user. I took this as essentially the same type of solution as A2. Not exactly, the main user interface window would have in this model a single DOM with no IFRAME (ie true content aggregation), the hidden iFrame being used as a backround content cache to be used by the main window to load content. A4 Erik has stated that he needs to be convinced that advanced client-side technologies as a viable market right now due to lack of standard support in IE which has a commanding share of the browser market. The minor issues with IE are well-known and can easily be worked around. Being able to workaround some product limitations does not in itself make the market viable. My gut feeling is still that the cost and complexity of deployment heavy client-side technologies are still much greater than the expected benefits. A5 Serge has stated that the current JSR 168 spec does allow portlet developers to take advantage a client-side technologies if they wish but it's a good thing that it does not require them to do so. Well, only if the developer writes all the aggregation code and puts in place all the necessary communication and window control mechanisms. Not exactly the way to insure a portable standardized approach. There would need to be a standard model developed and an implementation that demonstrated the ability of this approach to work in all scenarios. This is the type of thing that I'm looking for the spec to provide. I'm not sure I understand your comment here: of course somebody has to write the portal aggregation code and the communication mechanisms, just like we are working on implementing it on the server side with JS2. It's basically another portal project that you are talking about, this is completely out of the realm of the specification ! A6 Several people have expressed the importance of supporting light clients (like CHTML, WML, etc...) with the spec. Agreed. I don't see the two goals as conflicting. A7 Serge and myself have pointed out that WSRP would allow you to invoke a server based portlet and completely control the aggregation on the client. see A5 comment. About A2, I must point out that in this setup *no* real output aggregation actually occurs since iFrames are really independant documents based on independant HTTP requests. I find this setup - limiting cross-portlet communication (like you can't use request attributes to pass information around between portlets on the same page) and portal-portlet communication (how to you refresh a page navigation title based on a portlet content change if you don't reload the page ?) Is main page request attributes the only way that inter-portlet communication can take place? I would hope not. Well, you can sure use the session but there are additionnal costs and constraints associated with that and it's not always easily managed in clustered environments... - mush less efficient in terms of network and processing power for information oriented portals (like Yahoo), where probably 90% of the requests are read the page/update the page. In these scenarios the client-side code to download, the multiple request to process and possibly the larger amount of content you send out initially to the client to allow it to handle the minimize/maximize features without portal callback quickly add up to reduce the overall performance I really disagree with this assessment. Yes, you are making more requests but these requests are each much smaller. As far as sending the data for a minimize/maximize without callback, as I stated, you load the normalize view in the foreground and you load the maximize view in the background and the user will not experience any difference in performance. Well, you end up the same amount of markup in both case at the end of the process so the total useful transferred payload is the same, then in the IFRAME scenario you need to add the heavier client-side code and multiple requests overhead (for each request you need to do session validation, access control, etc...) so the client-side model both increase the amount of bytes transferred on the network and the computation costs on the server.
RE: JSR-168 Article Part 1 in JavaWorld
Can you please clarify how this operates. Are you envisioning a proxy requestor that will allow the main page DOM to remain intact. If so, then this may work. If not, then it definitely would not work. Yes the main page stays intact and all portlet url's targets would be the IFRAME proxy. I have not put a lot of thought into the specifics, so that is open to discussion. Obviously, the proxy IFRAME will have to do A LOT of DOM manipulation in the main page. Here is a simple scenario: My apologies if the diagram gets out of whack ;) User click Maximize on a portlet | -- This request is sent to the proxy IFRAME | | (The proxy IFRAME then checks if DOM Manipulation required?) || truefalse || The DOM is re-written to Nothing is done to the DOM facilitate the new window | state.| | | | | - | | The request is now sent back to the server to fulfill the JSR-168 requirements | Does the request response require a change In the target portlets content? | - | | true false | | re-write the DOMNothing is done to the DOM accordingly This is a very high level model of what I envision, it is by no means complete. *===* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Gerry Reno [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 1:02 PM To: Jetspeed Users List Subject: Re: JSR-168 Article Part 1 in JavaWorld Hi Scott, --- Weaver, Scott [EMAIL PROTECTED] wrote: Not exactly, the main user interface window would have in this model a single DOM with no IFRAME (ie true content aggregation), the hidden iFrame being used as a backround content cache to be used by the main window to load content. And act as the physical requestor back to the server. But yes, Raphael, this is exactly what I was getting at, using a single, hidden IFRAME, not an IFRAME for each portlet's content. Can you please clarify how this operates. Are you envisioning a proxy requestor that will allow the main page DOM to remain intact. If so, then this may work. If not, then it definitely would not work. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
The portlet spec is locking out client-side technologies!! If the arguments and points that I have presented have not convinced you then sobeit. I am not saying that the current spec does or does not lock out client-side technologies. I for one would rather say that it carefully avoids mentioning them. Some posters in this thread have started to suggest that maybe you can use some client-side technologies while still following 168. I don't know if that is realistic or not. What I am saying though is that the world of client-side is complex and unevenly supported by clients, I am suggesting that you make more concrete suggestions as to how a portlet specification could support them better than 168 does. Theory vs. practice, if you will. I can pretty much guarantee you that going forward with the spec the way it is it will fail. Wanna bet money? ;-) -Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSR-168 Article Part 1 in JavaWorld
I'm assuming that there would be an 'API' so that the developer would know how to talk to the proxy and request their portlet refresh. Developers should not need to be aware of this. We would have configuration options that would generate URLs that would be aware of this and possibly use javascript to intercept these requests and send them to the proxy. Like I said I don't have all the technical details figured out. We need to hide as much of the implementation as possible from the developer so their portlets can be used in portals that support JSR-168 but do not support the extended DOM interaction model you are proposing. Regards, *===* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Gerry Reno [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 4:11 PM To: Jetspeed Users List Subject: RE: JSR-168 Article Part 1 in JavaWorld Hi Scott, --- Weaver, Scott [EMAIL PROTECTED] wrote: Ok, but I still think that an optional Refresh button makes sense in some instances. Especially if you've set the TTL out very far and you then decide you want to refresh the portlet without refreshing the whole page. Of course, and that would be up to the portlet developer to provide that sort of functionality within his/her portlets. I'm assuming that there would be an 'API' so that the developer would know how to talk to the proxy and request their portlet refresh. rgds, Gerry Reno snip/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSR-168 Article Part 1 in JavaWorld
Hi Scott, I think you understand what I was proposing and how it has to operate to protect the contexts for client-side technologies. And it sounds potentially like you may have come up with a possible way to design and implement such a model. If this model can be successfully implemented then I think it should be incorporated into JSR-168. I think that is essential. rgds, Gerry Reno --- Weaver, Scott [EMAIL PROTECTED] wrote: I see the refresh option as porlet mode/render request, more than likely the doView() mode. *===* * Scott T Weaver* * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Weaver, Scott [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 4:29 PM To: 'Jetspeed Users List' Subject: RE: JSR-168 Article Part 1 in JavaWorld I'm assuming that there would be an 'API' so that the developer would know how to talk to the proxy and request their portlet refresh. Developers should not need to be aware of this. We would have configuration options that would generate URLs that would be aware of this and possibly use javascript to intercept these requests and send them to the proxy. Like I said I don't have all the technical details figured out. We need to hide as much of the implementation as possible from the developer so their portlets can be used in portals that support JSR-168 but do not support the extended DOM interaction model you are proposing. Regards, *===* * Scott T Weaver* * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Gerry Reno [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 4:11 PM To: Jetspeed Users List Subject: RE: JSR-168 Article Part 1 in JavaWorld Hi Scott, --- Weaver, Scott [EMAIL PROTECTED] wrote: Ok, but I still think that an optional Refresh button makes sense in some instances. Especially if you've set the TTL out very far and you then decide you want to refresh the portlet without refreshing the whole page. Of course, and that would be up to the portlet developer to provide that sort of functionality within his/her portlets. I'm assuming that there would be an 'API' so that the developer would know how to talk to the proxy and request their portlet refresh. rgds, Gerry Reno snip/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
You appear to be responding to the very beginning of the thread. You might want to read through the rest of the thread. I did read the whole thread. My comments regarded your initial post, hence I replied to it. They have made a number of improvements to support CSS. Agreed, they didn't implement the box model correctly in V5 but this is well known and easily compensated for. Really... By client-side technologies Im referring to Flash, SVG, applets, DHTML. These aren't at all flaky unless someone doesn't understand how to work with them. I like SVG, but no browser natively supports the technology, you have to use a plugin. Mozilla support is far from being complete and stable, and IE doesn't care. Applets not flaky: right! Totally disagree - round trips make for a completely annoying user experience and it's what is wrong with many sites. That's unfortunate, but that's the best we have IMO. Any proof-of-concept would have to come from those that are interally familiar with the implementation. Perhaps some Jetspeed team members might be willing to assist in producing such a proof. I really don't think it necessary. I think the arguments and points made in the thread speak for themselves. Out of the current 20 messages in this thread, 12 are by you, and *nobody* has made a single reply to any of your messages. My point is that there is no real discussion here, and no significant progress or definitive conclusion. The only arguments I see are yours, and of course you agree with yourself ;-) If you read through all of the threads dealing with the issue you will find examples of all of these things. I have, and I am not convinced. There are many applications and framework (mostly commercial) that have attempted to reproduce the desktop application model by delegating more of the UI logic in Web browsers. My experience so far is that they have all pretty much failed, in that they have been fragile, browser-dependent, and have not significantly improved the usability of Web applications. Just my $0.02 though. So I need to be convinced, that's all. -Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
Gerry, You are starting a debate very similar to the one around JavaServer Faces. Both JSRs strictly focus around a strictly server-side framework as opposed to a client-side framework (or a combination of both). To the defense of JSR-168, I think that client-side technologies are at best flaky, a situation that hasn't changed much in 4-5 years now. Microsoft hasn't made one significant improvement to IE since version 4. Mozilla has done better, but represents an almost insignificant market share. There is just not much happening in that arena today, partly because of IE's monopoly. The question of chosing a technology common denominator is difficult. The trend in the past few years has been to go back to server-side technologies generating pretty basic HTML, JavaScript and CSS. Today, the Web sites and Web apps with the best usability IMO are the ones that try to minimize the use of fancy client-side technologies. In theory diminishing the number of round-trips to the server is better, but the reality is that round-trips work! In addition, the JSR must allows for different types of clients, such as PDAs. It also must be 100% agnostic wrt the technology used for the presentation (JSP, XSLT, etc.). Clearly not everybody has standardized on JSP. I think some of your concerns are valid (but not too important to somebody like me I have to say) but remain way too theoretical. The best approach to convince people would be to point to an implementation addressing them. Such an proof of concept could be a good basis for inclusion in a JSR. -Erik Gerry Reno wrote: 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-userm=105850057414235w=2 http://marc.theaimsgroup.com/?l=jetspeed-userm=105846310309122w=2 Unfortunately there appears to be no latitude in the spec. The JSR-168 spec is supposed to permit creation of Enterprise Information Portals (EIP) using standardized portlets that are portable. This is good. But, I think that a lot of people have got themselves so caught up in the portlet lifecycle and the API and the storing of persistent portlet data and how do I create a __ type portlet and all the rest that they are failing to look at a bigger picture of some of the human-factors and user-experience perspectives and expectations with regard to web enterprise information portals. From my perspective this is very important since JSR-168 is going to be declared *the* standard. The standard should provide enough flexibility to accomodate all the common types of paradigms and technologies to which users have come to use when utilizing the Web. The portlet spec as currently written is analogous to having a number of browsers open on your desktop and each one would represent a portlet and if you were to hit the reload button or minimize or maximize or submit a form from any of them, then all of them would reload their pages. Well this works great if you don't mind losing any client-side processing that is going on. The problem is that users are accustomed to having client-side processing and in fact expect a consistent context when interacting with client-side technologies. As it stands now, the portlet spec is dictating that every portlet mode or window state change causes an action request to be sent to the server. If you understand how the browser and pages and the document object model and browser client-side technologies work you immediately realize that constantly reloading pages is not a good thing. Ok, let's look at a real simple example. A user is interacting with an information rich JSR-168 portal. In the portal there is a media player portlet that allows the user to select from a list of available videos to view and there are other portlets on the page for various other information purposes. While the user is viewing a video presentation, one of these other portlets is doing something distracting and the user would like to minimize it so that the user can concentrate on the video presentation. Under the current JSR-168 spec the user's action to minimize this portlet results in a page request being sent back to the server which in turn results in the page being reloaded. What that does is destroy the original document object model (DOM) in the browser representing the original page and the subsequent creation of a new DOM representing the newly reloaded page. All running embedded client-side technologies such as applets, DHTML, javascript, Flash, SVG, etc. etc. are destroyed losing their contexts. The browser then redraws the reloaded page and all the portlets and initializes and starts all client-side scripts, modules,
Re: JSR-168 Article Part 1 in JavaWorld
In the broader scope, what I think is necessary for both the portlet spec and for things like jsf is that anytime you are going to require maintaining the contexts for client-side technologies it is necessary that the main page not be reloaded and that the client interact with the server-side technology via a client-side controller/proxy talking to iframes which can be reloaded independently of each other and the main page. This lets you have the best of both worlds - enterprise-level server-side processing and rich, robust and fast client-side technologies. rgds, Gerry Reno --- Gerry Reno [EMAIL PROTECTED] wrote: Hi Scott, --- Weaver, Scott [EMAIL PROTECTED] wrote: Gerry, Here is how I envisioned it. You would have a Request Proxy probably a hidden IFrame that has the ability to write both to the client (DOM manipulation/screen repainting) and the server(record the user's current page and portlet state/process non trivial portlet requests). This is over-simplified but gives you an idea of how I think it could be implemented. The client-side portlet controller should exist in the main page not in it's own iframe. That would be destroyed anyway if the main page were reloaded. The key is that the portlets have to exist in a framework that allows them to be manipulated separately - the only construct that is currently capable of this in a browser is the iframe. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE : JSR-168 Article Part 1 in JavaWorld
Not exactly, the main user interface window would have in this model a single DOM with no IFRAME (ie true content aggregation), the hidden iFrame being used as a backround content cache to be used by the main window to load content. And act as the physical requestor back to the server. But yes, Raphael, this is exactly what I was getting at, using a single, hidden IFRAME, not an IFRAME for each portlet's content. *===* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Luta, Raphael (VUN) [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 12:18 PM To: 'Jetspeed Users List' Subject: RE : JSR-168 Article Part 1 in JavaWorld De : Gerry Reno [mailto:[EMAIL PROTECTED] snip/ I'll try summarize what has been said so far (I hope I will not miss a major point somewhere) : A1. you advocate the need for a strong support of client side technologies in the JSR 168 portal specificcation Correct. A2 you propose a portal implementation model based around portlet content included in IFrame tags and a persistent client-side controller in the main page. Yes. A3 Scott has proposed an alternate implementation model for the client side based around a reqsuest proxy to a hidden iFrame that is manipulated by the main window, which is interacting with the user. I took this as essentially the same type of solution as A2. Not exactly, the main user interface window would have in this model a single DOM with no IFRAME (ie true content aggregation), the hidden iFrame being used as a backround content cache to be used by the main window to load content. A4 Erik has stated that he needs to be convinced that advanced client-side technologies as a viable market right now due to lack of standard support in IE which has a commanding share of the browser market. The minor issues with IE are well-known and can easily be worked around. Being able to workaround some product limitations does not in itself make the market viable. My gut feeling is still that the cost and complexity of deployment heavy client-side technologies are still much greater than the expected benefits. A5 Serge has stated that the current JSR 168 spec does allow portlet developers to take advantage a client-side technologies if they wish but it's a good thing that it does not require them to do so. Well, only if the developer writes all the aggregation code and puts in place all the necessary communication and window control mechanisms. Not exactly the way to insure a portable standardized approach. There would need to be a standard model developed and an implementation that demonstrated the ability of this approach to work in all scenarios. This is the type of thing that I'm looking for the spec to provide. I'm not sure I understand your comment here: of course somebody has to write the portal aggregation code and the communication mechanisms, just like we are working on implementing it on the server side with JS2. It's basically another portal project that you are talking about, this is completely out of the realm of the specification ! A6 Several people have expressed the importance of supporting light clients (like CHTML, WML, etc...) with the spec. Agreed. I don't see the two goals as conflicting. A7 Serge and myself have pointed out that WSRP would allow you to invoke a server based portlet and completely control the aggregation on the client. see A5 comment. About A2, I must point out that in this setup *no* real output aggregation actually occurs since iFrames are really independant documents based on independant HTTP requests. I find this setup - limiting cross-portlet communication (like you can't use request attributes to pass information around between portlets on the same page) and portal-portlet communication (how to you refresh a page navigation title based on a portlet content change if you don't reload the page ?) Is main page request attributes the only way that inter-portlet communication can take place? I would hope not. Well, you can sure use the session but there are additionnal costs and constraints associated with that and it's not always easily managed in clustered environments... - mush less efficient in terms of network and processing power for information oriented portals (like Yahoo), where probably 90% of the requests are read the page/update the page. In these scenarios the client-side code to download, the multiple request to process and possibly the larger amount of content you send out initially to the client to allow it to handle the minimize/maximize features without portal callback
Re: JSR-168 Article Part 1 in JavaWorld
Hi Erik, You appear to be responding to the very beginning of the thread. You might want to read through the rest of the thread. --- Erik Bruchez [EMAIL PROTECTED] wrote: Gerry, You are starting a debate very similar to the one around JavaServer Faces. Both JSRs strictly focus around a strictly server-side framework as opposed to a client-side framework (or a combination of both). To the defense of JSR-168, I think that client-side technologies are at best flaky, a situation that hasn't changed much in 4-5 years now. Microsoft hasn't made one significant improvement to IE since version 4. They have made a number of improvements to support CSS. Agreed, they didn't implement the box model correctly in V5 but this is well known and easily compensated for. By client-side technologies Im referring to Flash, SVG, applets, DHTML. These aren't at all flaky unless someone doesn't understand how to work with them. Mozilla has done better, but represents an almost insignificant market share. There is just not much happening in that arena today, partly because of IE's monopoly. The question of chosing a technology common denominator is difficult. The trend in the past few years has been to go back to server-side technologies generating pretty basic HTML, JavaScript and CSS. Today, the Web sites and Web apps with the best usability IMO are the ones that try to minimize the use of fancy client-side technologies. In theory diminishing the number of round-trips to the server is better, but the reality is that round-trips work! Totally disagree - round trips make for a completely annoying user experience and it's what is wrong with many sites. It only works from the standpoint of being able to pick up server-side data. In addition, the JSR must allows for different types of clients, such as PDAs. It also must be 100% agnostic wrt the technology used for the presentation (JSP, XSLT, etc.). Clearly not everybody has standardized on JSP. I think some of your concerns are valid (but not too important to somebody like me I have to say) but remain way too theoretical. The best approach to convince people would be to point to an implementation addressing them. Such an proof of concept could be a good basis for inclusion in a JSR. -Erik Any proof-of-concept would have to come from those that are interally familiar with the implementation. Perhaps some Jetspeed team members might be willing to assist in producing such a proof. I really don't think it necessary. I think the arguments and points made in the thread speak for themselves. The current portlet spec completely destroys the capabilities of client-side technologies. In fact, some of the existing portlets do not even function properly due to the interaction model being dictated by the spec. If you read through all of the threads dealing with the issue you will find examples of all of these things. rgds, Gerry Reno __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSR-168 Article Part 1 in JavaWorld
Hi Serge, --- Serge Huber [EMAIL PROTECTED] wrote: At 08:32 AM 8/6/2003 -0700, you wrote: Hi Raphael, --- Luta, Raphael (VUN) [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSR-168 Article Part 1 in JavaWorld
If we used client-side operations to alter window state, how would we maintain/persist a user's window state when that user closes their browser? What if a user logs in from a different browser on a different machine, wouldn't they expect the state of there portlets to be same no matter where they are accessing the portal from? *===* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Gerry Reno [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 11:58 AM To: Jetspeed Users List Subject: Re: JSR-168 Article Part 1 in JavaWorld -trying to tie this linkage back to the original thread - De : Gerry Reno [mailto:[EMAIL PROTECTED] Hi Raphael, --- Luta, Raphael (VUN) [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
