Information
| Description | A channel to allow selection and inclusion of content generated and maintained by an external CMS system |
|---|---|
| Audience | Portal Administrators, Content Administrators |
| Category | General Channels |
| Priority | medium |
Interested Parties
John Feriera (Cornell), Jason Shao, Cris J. Holdorph, Tom Tom, Elliot Metsger (JHU), Ryan Shelley (CSUN), Howard Kim (UCLA), [Gaston Gonzalez] (UCR), Katya Sadovsky (UC Irvine), Natalie Godfrey (UC Irvine), Patrick Berry, Robert Sherratt (U Hull), Lennard Fuller
Resources Available
Vision
A channel/portlet that allows users to select content from an external CMS to include within a uPortal install. Some kind of interface which allows selection of content, partnered with the ability to display content from the CMS, and possibly build navigation to allow navigation within a tree, etc.
This is NOT envisioned as connecting to specialized systems like LMS, VLE, etc - more of a way to get structured, static content into a portal instance.
Notes
- lots of interest
- first steps probably involve surveying which CMS's are in common use, and what if any remote APIs they may have for content
- Could use to pull Confluence content into clearinghouse for instance
- users & permissions
Possible Integration Candidates
JSR 170 Compatible
- Jackrabbit
- Alfresco
- Also offers an open source JSR 168 portlet. With a small number of modifications to the war this portlet can be deployed and published into uPortal 2.5.3 successfully.
- eXo (yes, they have a JSR 170 implementation as well as a portal)
- jeceira (project does not seem to be very active)
Hypercontent
- GAPS compatible?
- JA-SIG product
Plone
- Built on the Python based Zope Application Server
Confluence & Other Wikis
- used by clearinghouse
- Web Services / remote SOAP/JAX-RPC apis
- Better/Alternative RSS support
Sharepoint
- lots of people seem to have installations
Blogs
- Movabletype, Wordpress, Blogger, etc.
Atom Support
- IETF proposed standard (RFC4287)
- Syndication Format
- Publish/Author Format
Comments (7)
Sep 13, 2006
Patrick Berry says:
I'm using Movable Type in conjunction with webproxy channels because MT is best ...I'm using Movable Type in conjunction with webproxy channels because MT is best at producing static files and we can also reference URLs through the load balancing system we have. These files get rsync'd to each tomcat instance in our portal production pool. Content contributors can control when files are sync'd. All "in channel" links can be marked so as they load in the channel and other links can have the target attribute added.
If anyone is interested in this setup I can go into more detail.
Sep 14, 2006
Robert Sherratt says:
We currently have a crude but effective and now old IChannel to achieve this. Al...We currently have a crude but effective and now old IChannel to achieve this. All of our content is published via a CMS (HyperContent)to a static web site. A scraping channel then reads the content in (based on HttpReader from CWebProxy), parses it and displays it to the end user. We are in the process of moving to 2.5.2 and once this platform is stable I want to portalize this channel. I would also be interested in the direct call to a CMS (HyperContent) to extract the correct content and extending this to read more generic web content such as blogs/wikis/atom noted above.
Sep 26, 2006
Robert Sherratt says:
One other thought on this, we should also be looking to ensure this works follow...One other thought on this, we should also be looking to ensure this works follows the lead taken by Rutgers on global content caching which should dramatically improve portal efficiency.
Sep 26, 2006
Alex Vigdor says:
I'm working on a portlet wrapper for HyperContent 2.0, so it will soon be possib...I'm working on a portlet wrapper for HyperContent 2.0, so it will soon be possible to serve content directly into the portal from HC without the overhead/bottleneck of HTTP calls in CWebProxy. This won't provide a general purpose solution, but will create a compelling integration between these two JA-SIG products.
The main piece of the wrapper just takes an HC output path from the deploy or publish time properties and writes the content that HC renders for that path directly to the portlet output stream. I've also written a link-rewriting filter that allows any cached or dynamic HC output to be browsed inside the portal context, much like in CWebProxy. Installing the portlet also gives you the full-fledged HyperContent servlet alongside the portal, although it will be possible to disable the asynchronous batch processor in a scenario where you want to have a separate dedicated machine or JVM to handle HC's heavy lifting, keeping resources free for the portal.
The main remaining piece is "edit-in-place" support. I'll keep you posted on my progress!
Sep 27, 2006
Jason Shao says:
Alex are you planning on embedding Hypercontent into a uPortal instance then. So...Alex - are you planning on embedding Hypercontent into a uPortal instance then. So we'd have distribution of uPortal that included essential servlet mappings for HC & the guts required to make them work, and a portlet for admin/rendering content into user layouts? Perhaps used as part of a Portal + CMS distribution?
Sep 27, 2006
Alex Vigdor says:
Yes, this is HyperContent embedded in uPortal, with full standalone functionalit...Yes, this is HyperContent embedded in uPortal, with full standalone functionality also available thanks to the webapp portlet deployment (which automatically enables the standalone HC servlet under its own context). I checked the portlet rendering piece into the HC cvs this morning; in my dev environment I'm using it to serve the CAS web site into a browseable portlet. The next step will be creating admin/edit screens that are tailored to portlet presentation, but there's already enough there to do a proof-of-concept serving content directly into the portal without static publishing or HTTP calls.
A major limitation at this point, due to the bug UP-1040, is that each HC-managed portlet has to be defined in the portlet.xml, requiring a restart. Once that bug is fixed we should be able to define a single portlet in the xml descriptor, and each published instance could override the "path" setting to define its entry point into the CMS, so new managed portlets could be added at runtime. It would even be conceivable that the default path would render a screen allowing you to create a new piece of content to populate the portlet, or to browse existing content. For now the default screen is the HC dashboard, which just links out to projects in the standalone servlet.
Another caveat is that the version of Pluto that comes with uP has a bug which prevents the rendering of non-text content (i.e. images, PDFs, etc), but the 1.0.1 final release which was just checked into the uP head solves this problem.
Once we get the kinks worked out and develop some further proofs-of-concept, I definitely think a combined uPortal+HyperContent distribution would be a compelling product!
Oct 17, 2006
Lennard Fuller says:
It is important to note that in comparing HyperContent and a JSR 170 implementat...It is important to note that in comparing HyperContent and a JSR 170 implementation, one is not making an 'apples to apples' comparison. A CMS which provides a JSR 170 api is something with which one can create a rich content management application i.e. possibly something like HyperContent. There are a growing number content management applications which have chosen to build upon the JSR 170 specification. Such a choice allows an application to avoid dependance upon a specific vendor or open source implementation as well as avoiding the need to reinvent a great many CMS 'wheels'. Please note that some communities and/or vendors which provide a JSR170 implementation may also provide content management applications which are built upon the JSR170 implementation. Therefore someone saying 'Alfresco' maybe refering to their JSR170 implementation or their open source content management application.