Ozgur,

Many thanks for the information. In my case, it is acceptable that remote
URLs served by WebPagePortlet aren't refreshed immediately. Currently,
neither FileServerPortlet nor WebPagePortlet will refresh at all. I got it
to work by adding the following line of code in the init() method (after the
call to super.init()):

this.getExpire().isExpired();

With this change, FileServerPortlet will refresh its content as soon as it
changes and WebPagePortlet will refresh its content when DiskCacheDaemon
"sweeps" the cached URLs (hourly by default).

You're right, there are a lot of issues with external content. We have set
special requirements that external content must meet before it can be hosted
within the portal.

Your approach is interesting though and I could find other uses for that. If
you'd be so kind to post your code, that would be great. Thanks!

Best regards,

Mark C. Orciuch
Next Generation Solutions, Ltd.
Voice: 219-365-0691
e-Mail: [EMAIL PROTECTED]
web: http://www.ngsltd.com


-----Original Message-----
From: Ozgur Balsoy [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 31, 2001 6:44 PM
To: [EMAIL PROTECTED]
Subject: Re: Automatic content refresh (FileServerPortlet and
WebPagePortlet)



My observation is that both the FileServer- and WebPagePortlets work for
only one URL per portlet. These URLs' contents are converted into ECS
element trees and cached. Whenever the pages expire, these content trees are
renewed.

To solve this problem, I have altered WebPagePortlet so that the converted
URLs look similar to this:


http://jetspeed-host/jetspeed/portal?mynewurl=http://converted-full-url/some
path

My new WebPagePortlet gets this parameter, downloads the content and
refreshes the page at each click. This way I can continue to surf the Web
within the Jetspeed page.

There are problems with this approach of course.
- For each click, your portlet makes another URL connection which brings
some more overhead to the portal. For revisits, cache service can be used.
- A lot of pages do not fit into the Jetspeed screen , i.e. frames, dynamic
HTML, colors, styles, fonts...
   (Currently I can copy the background image and bgcolor of the page inside
the portlet, and I'm working on styles and fonts.)
- Forms require special treatment. (I'll work on this,too.)

This method is perfect if you have distributed content, maybe behind a
firewall, to represent inside a portal. The content must be simple and
carefully written for this purpose.

I can share my code but it is kind of messy right now.

Ozgur Balsoy
Pervasive Technology Labs
Indina University

-------------------
From: Mark Orciuch
Subject: Automatic content refresh (FileServerPortlet and WebPagePortlet)
Date: Tue, 18 Dec 2001 09:27:58 -0800

----------------------------------------------------------------------------
----

If FileServerPortlet is extending the FileWatchPortlet, then shouldn't it
also support the automatic content refresh when the underlying URL changes?
Was the original intention to have another portlet which would support file
watching capability? What about the WebPagePortlet - it is also extending
FileWatchPortlet yet it does not refresh itself when the underlying URL
changes.

I was able to pinpoint why FileServerPorlet does not refresh itself when
changed (I can provide a patch if it's appropriate). However, for the life
of me, I cannot figure out how to make WebPagePortlet work that way. I
understand that local URLs are treated differently than remote ones and that
remote URLs are refreshed at predefined intervals by the DiskCacheDaemon.
Could someone please comment on whether my observations are correct? Thanks!


Best regards,

Mark C. Orciuch
Next Generation Solutions, Ltd.
Voice: 219-365-0691
e-Mail: [EMAIL PROTECTED]
web: http://www.ngsltd.com


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to