Auto-Refresh

[former_member235792]

Wondering if anybody can give me any ideas as to whether or not this can work in a portal environment.

There is an open source solution for auto-refreshing called pushlets. On the client side, it basically is an HTML page with two frames. One frame is the display and the second frame calls a servlet which subscribes to a certain subject (through a parameter). When a response is returned from the servlet, the response calls a javascript function in the main HTML page to refresh the display frame (or display new data from the servlet response). I've already proven that these pushlets work in a non-portal environment...However, I am having trouble trying to integrate it into a portal environment.

Any ideas???

[former_member235792]

Thanks Oliver,

The idea I came up with was to use two iViews. One iView acting as the "so-called" display frame. And of course the second iView acting as the frame which calls the servlet. Then in the response from the servlet, I would raise an event using EPCM in javascript. The display iView would be listening for this event and then reload the iView.

Another problem I am having is that in the pushlet framework, there is a Publisher class. This class has only one instance running at all times. This Publisher keeps track of the subscribers and also dispatches the events to the correct subscribers. I don't know how I can create this Publisher in the portal framework.

What do you think Oliver?

Chris

[Oliver_S]

well, seems to be a good design, if it is implemented correctly, you will not have flickering pages any more.

Regarding the publisher class. If i understood Java correctly - all classes may have class variables (in fact internally - the header of a class in one classloader exists always only once). This is the shared memory concept of java.

In EP implementation you have to take care of the classloaders. The publisher class should only be loaded once by one defined classloader and should - if I understood you correctly - receive all http requests from the Portal.

This is only the case for the PRT (portal runtime) itsself. Maybe there is a possibilty. Check the PRTGuide in SDN, which explains the PRT API quite detailed.

Oliver

[former_member235792]

Thanks again Oliver,

Actually, after some further thought I don't think this design would work for me. I need to send parameters into this servlet. Let me go into further detail of the pushlet framework. The client calls the Pushlet servlet with a subject parameter (what information the client is interested in). This servlet creates a Subscriber instance and this Subscriber instance adds itself to the Publisher list of Subscribers. In my case, an R/3 system will call a Postlet servlet (also with a subject parameter and additional data parameters) which will publish an event in the Publisher. The Publisher receives this new event, checks the subject, and dispatches the event in the form of a javascript call to the Subscribers listening for the event subject.

If I execute the Pushlet servlet as a portal component, I don't think I'll be able to send parameters. In my case, the subject parameter would be based on what is selected in the "display" frame. Plus, the Postlet servlet (which is called by an R/3 system) would need to have access to the Publisher in order to publish the event. If the Publisher is in the Portal Runtime, I don't think that's possible unless the Postlet is in the Portal framework. And if the Postlet is in the Portal framework, I don't think an R/3 system can access it.

For more detailed information on Pushlets, go to http://www.pushlets.com

Chris

[former_member235792]

Sorry let me add to the information above. The Pushlet servlet, after creating a Subscriber instance, waits for a response. And the response is the Publisher dispatching the event in the form of a Javascript call.

I just wanted to make it clear as possible.

Chris