On Jul 31, 2007, at 3:57 PM, Parker Grimes wrote: > I would also be interested to know how other schools have > approached this. We are considering making the portal guest page > the default browser home page on all of our campus computer labs. > We wouldn't want the page to be completely static, for instance we > would like a weather portlet and some campus news RSS feeds to be > displayed. It seems like a waste of our uPortal resources to be > required to render all of that stuff all of the time. What about > "mimicking" the portal home page with a simpler technology like > php, ruby, or django? Or is it not that big of an issue to just let > uPortal handle the load assuming we have caching working on our side? > > On 7/31/07, George Lindholm <[EMAIL PROTECTED] > wrote: > Hi all, > I'm thinking about putting a static version of the guest page in > front > of our > uPortal to minimize the guest sessions. So I just wondering what other > sites have done and what their experiences have been?
myRutgers always took the static welcome page route. If you visit https://my.rutgers.edu (the only part of myRutgers outsiders can really get to, other than the tour) -- that page is basically just a static HTML page served up by Apache. I know myRutgers also includes a Session Management hook that I think was originally obtained from UBC -- if you are interested Faizan may be able to provide more details. If enough people are interested, this may even be a good candidate for inclusion in uPortal 3 under the currently being discussed path forward [1]. Having said that... myRutgers trades low resource consumption for a relatively static front page. In the past we had tossed around ideas for possibly periodically generating the page using something like Cron, or switching to a JSP. A session=false JSP, backed with some cached SpringMVC-wired beans doing RSS retrieval and WeatherService lookups for example should be quite performant. While Guest layout is likely a reasonable approach for many, and gives interesting options of easily customizing the front page based on attributes like IP, or referrer using the same frameworks as the rest of the portal, you also lose many of the benefits of the layouts, since you don't have a lot of user attributes, and you can't persist user changes. Especially if you're doing lightweight content integration into your portal using something like RSS or web- services, duplicating a simplified layout via another technology is probably low-effort to meet this particular use case. Jason -- Jason Shao Application Developer Rutgers University, Office of Instructional & Research Technology v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] | http:// jay.shao.org -- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
