It needs to recognize and specify how users can utilize portlets in both a server-centric manner and a client-centric manner.
I think this is a good statement. A portal and especially a portal spec should support both technologies. The developer can than decide which technology he/she uses.
I agree with you, Raphael, that one should use standards where possible and suitable. But there are solutions that can�t be well done by standards. My customers normally don�t care if I used standards or not. They just want a solution that fits exactly their demands and in my opinion the customer should say the last word.
So technology should not live on it�s own, it should rather involve the customer demands.
Helmut
Gerry Reno schrieb:
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]
