Steve Williams said: >> "2. A software framework to make building, managing and >> deploying #1 easier. >> The CMS should provide capabilities to support #1, but it > > will rarely do #2. > > I agree that a portal is a software framework, but I don't > agree that a CMS will rarely do this. Why ? Because it depends on the > software framework we are talking about. > > It also depends on what the customer understands under the > word 'portal' - as it can quite often be simply a request for rule > based, personalised content.
Quite. Which is why I was careful to define the terms the way I did, so saying "it depends how you define it" is just a tad dubious... B-) I was particular in my definition, because crucially portal (as I think we started discussing it) is predominantly a *delivery* side technology. Sure, it needs critical features on the content management side to make it work - appropriate storage and access to content, taxonomies, metadata, search, KM, etc, etc. My thinking behind this is that the #1 definition of portal (user interaction model) grew over time as a result of experience and best practice in presenting information, often (as you rightly observe) in a personalized manner. Once common features started to emerge, you then saw the development frameworks (#2 definition) to make building them easier and to take care of the grubbier aspects of layout, UI behaviour, deployment, management and all that stuff. You can see the close link with personalization in the vendors have actually renamed the products from personalization to portal servers without changing much. I don't think right now that these frameworks are provided by CMS vendors, who are largely concerned with providing access to content in a manner that supports personalization/portal as I described above, because many CM vendors are just not interested in delivery. You are right in that CM vendors who include delivery technology can do some aspects of portal (group based personalization, for example), and componentized templating can be useful in building portal UIs, so arguably that might be seen as a "framework". But I draw a big distinction between those and the "big boy" frameworks like a WebLogic Portal. Those kind of frameworks are just not core business for CM vendors right now. As I said, they do so much more than the UI, including management, deployment, and so on. Over time, you are right... the CM vendors are getting into this game for the usual reasons, and initially they'll do it by acquisition and partnership. Vignette have chosen to do it by buying a portal vendor, most have done it by building "adaptors" into the portal products and pre-built "portlets" to make the integration job easier. The other force that will come into play later is the development of standards for the portal frameworks (there's a JCP JSR on the subject, I forget the number). With that, and the JSR defining an API for CM systems, we're in for an interesting couple of years... -- S -- http://cms-list.org/ trim your replies for good karma.
