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