> 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 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. > If you load the maximize view in the background, you are transferring > additional bytes on the network and consuming cpu cycles on the server > *which will be wasted if the user does not maximize a portlet*. > So all in all, the client-side approach requires more resource on the > network and on the server if you consider information portals. > > > >- 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. > > > > I guess it depends on the size of your wallet, but validating a DHTML > site full of JS/DOM/CSS-P code is sure way more expensive than > validating one with simple HTML4. > > > >- 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 > > >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. > > > > I understand WSRP and setting up client-side aggregation. > > But that whole model, if it can be proven to work and to > > protect client-side technologies, needs to be part of JSR-168 > > then. Otherwise, you'll have no standard type of > > implementation that portlet developers can target. > > There may need to be some types of portlet attributes such as > > 'persistent', 'non-persistent' and perhaps others that would > > apply in a client-side aggregation model. > > > > WSRP and JSR-168 are designed to work together, even though are > two different specifications. > > Also check out: > http://nagoya.apache.org/wiki/apachewiki.cgi?CharonProposal > > -- > 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]
