> 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]
