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 the basis of this
message is prohibited.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
