Ok, been thinking more about things discussed in this threadhttps://xoops.org/modules/newbb/viewtopic.php?topic_id=25208&forum=20&post_id=110780 and have a question for those that may have more experience in using proprietary systems, what is a good example of a true feature rich CMS system? Please note, I do not mean a portal or application framework like Xoops, but a true content oriented system.

I'm trying to get an idea of all the functionality that would be required to make a viable content management module. Not simply an article management module like WF-sections, but something more along the lines like Vignette (but obviously not quit that complex). Only problems is I don't have access to this [Vignette] system, so I need something with similar functionality that has a demo I can use to get an idea of how work flow etc is managed.

I know plone was one suggested in another thread, any others?

I believe ezPublish is a similar system.

Typo3 is far to complex and, in my opinion, not very user friendly.

I suppose Mambo is more along the lines of CMS than application framework/portal.

Quote:
I can hardly consider XOOPS as Application Framework, really

Quote:
From by POV - it's best iteration (besides it's complexity), but it's PHP anyway...
Quote:
I added Mambo in my list of "simple portals" after try, somewhere below Xoops, near e107, ezContent, JetBox...

You can see also at Sitellite.

But - if I'll must use real, pure CMS|CMF, I'll stay with eZPublish. It will require a lot of time, hard work, attention, but - I'm (almost) ready to spent part of my life to eZPublish

@Draven:

This is a good question, and something that I am asking myself too. But I think it would be more useful to gather requirements from the end-user perspective rather than just consider "cloning" some functionality from another system.

The only things that come to mind straight away as lacking in XOOPS are Metadata and workflow. Does anybody know of a good link about CMS requirements? All I can find is this one:

www.lassa.org.uk

Andy

I have been thinking about this a lot too, and I ahve some ideas on this.

First of all, I make a presumption here that there are 3 layers to every system:
Presentation (user interface)
Application (logic, added value)
Data (storage, database)

This is a common and simple model used everywhere in IT. So this shouldn't be too strange to work with.

Now, I see the true CMS only active in the Application layer. It's the logic that puts the right data from the right sources, to the right people in the right format.
Lots of CMS's (and XOOPS is no exception to this) focus on presentation and are basically portal scripts. They merge the two top layers (I don't know of a CMS that uses it's own database).

A CMS should focus on what it is: a system to *manage content*. Ideally, a CMS would be independant of the presentation (internet site, intranet site, mobile devices, print, electronic documents), and data source (databases, documents, XML messages etc.) All it does is get the right data from the right source, routes this to the correct content manager, offers it for approval or editing, and then routes it to the presentation engine for processing. How the content is edited, is not dependant on how it is presented (meaning that it should not be restricted to a web browser if it is for a website).

I realise this is a very purist view on CMS's, but it helps to make a point in this discussion:
A real CMS should not deal with end-user features (as that is the presentation layer), or database and storage (data layer), but with content routing. So essentially, it's a workflow management system with a focus on content.
XOOPS is a portal script that is moving (slowly) towards some real content management features and uses some 3rd party database and storage technology. I think that if we want to earn the title of a CMS we have to get away from the end-user for a bit (the website visitor) and think of how a content manager manages his/her content. This means:
- Content routing;
- Metadata;
- Workflow management;
- XML input and output;
- Global knowledgemanagement features;
- Probably lots more.

I don't know if we would want to earn this CMS title, but I would like to see this concept working in XOOPS, one way or another.

Herko

By "end-user perspective" I didn't just mean the web-site vistor, I was meaning all the people who interact with the system. Or to be more specific; "Actors" in RUP/UML terminology. So "Content manager" and "Site vistor" are just two examples of Actors in the context of a CMS. I wonder if there are more....hmmm....

Quote:

Good list! We should continue defining what they mean....

Andy

I'm working on the integration of the GALAXIA Worklfow engine in XOOPS.

XOOPS Workflow xflow

It's clear that a workflow engine is very important in a CMS. It could be use for all the modules.

A funny thing happened today. At work, I had a discussion with Johnathan Murray, CTO of Microsoft EMEA, and Jean Paoli, one of the co-creators of XML 1.0 and chief XML architect for Microsoft, about their XML strategy. And the funny thing is, when they explained their strategy with Office 2003 and WordML, which is an open XML standard for documents, they basically said that the Office 2003 suite is what I described as a Content Managemant System, one that allows editors to create data and store it independant of presentation. Using XML, SOAP, XSLT etc. this info can be presented in any way, shape and form, and stored in databases, flat files or whatever you want...

If Microsoft has made this their general business strategy (and remember who I talked with, not the worst sources), then I think that this could very well be a sound strategy for XOOPS: CMS+Portal

Herko

If XOOPS were to take this road for future development and seperate presentation, aplication and data. How exactly would this change XOOPS as a whole? I can see how a better separation between presentation and aplication would impact site creation. Isn't that what smarty is for?

SMarty is part of that story, yes. And XOOPS3 development plans are going towards this picture. But essentially, what it means is that XOOPS should be able to get any (standardised) input (XML, database etc.), and create any (standardised) output (Smarty, XML, whatever). At least it should be possible to add your own input and output layers, so you can make this work with pretty much any back- and frontend.

This means XOOPS development should focus on 2 things:
- true COntent Management: creation, editing, versioning, routing and enrichment of content (text, images, sound, etc.).
- Front end Portal: content output presentation, organisation and distribution.

I realise that this is quite a fundamental discussion, but as I said before, it helps the process of discussing the fututre of XOOPS


Herko

I think that what Herko meant to underline () is that the three-tier system should be sharper defined than it is today.

Smarty is a step on the way towards it, but in order to be truly platform-independent also on the presentation level, we will need the business layer to output a standardized output, which is subsequently presented by the presentation layer.

As it is now, it is heavily relying on the presentation layer to use HTML. We have a text sanitizer that converts to HTML - this ought to be on the presentation layer so that if someone was to create a PDA or Application program to use the XOOPS platform, it would just apply its specific presentation logic to the data. The basic idea is that one should use the business layer to get the information in this standardized format (XML would be a natural choice) and then one could have a PDA application to convert the XML into data presented on a PDA, the application would convert the XML into data presented in a Windows/Linux application and the browser would convert the XML into HTML.

Of course that implementation is not all that relevant as PHP is a webserver-interpreted language, but with the emerging adoptance of web services, one could theoretically have a Windows application, e.g. written in C#, calling web services on the webserver running XOOPS and getting data back, which should then be presented in the application. In such circumstances, it would be undesirable to get HTML back - e.g. text articles with HTML tags in them.