Forum OpenACS Q&A: cr/cms feature list

Collapse
1: cr/cms feature list
Posted by David Kuczek on 08/11/02 02:02 PM
This thread emerged from the thread "ACS-JAVA + PostgreSQL"
(https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0004Vv)

I just made the experience that whenever a company decides for a cms
product they contract a consultant who sets up a list of cms features.
Only those companies that *fulfill* this feature list are envited to a
presentation. There are consultants with a lot of experience in
technology and others that copy their feature list from some cms book
(most often I believe). On the other hand there are executives that
decide on bells and whistles (most often I believe) and others that
have experience with technology.

I will see that I can get a feature list together that a cms is
evaluated on. This might lead us to a solution, how we should set up a
cr/cms vertical...

Jun, Don, others... any suggestions for this list already?

Collapse
2: Response to cr/cms feature list (response to 1)
Posted by Jun Yamog on 08/11/02 03:42 PM
Hi David,

As far as I seen there are 2 things:

1. CMS = site builder. This is very much how my modetp works now. It builds a site. But since there are still layout on the page its not really a CMS.

2. CMS = stuffing content and presenting content. This what we should aim for. And also OACS has already this capability in its CMS.

I am already investigating item #2. As for UI openCMS has pretty nice UI for a OSS CMS. Cofax has the right concept. But just like what I said no super UI will solve our problem. So the best way to approach this is to make OACS CMS into pieces so it can be assembled to a client need or vertical need.

On the side note while doing #2:

For some weird reason PG gets confused with content_item__new. So I had to explicitly type cast the parameter.... 

			select content_item__new (
			:item_name,			-- name
			integer :parent_id, -- parent_id  for some reason PG gets confused on this param, explicit typecasting was needed
			null,				-- item_id
			null,				-- locale
			now(),				-- creation_date
			:creation_user_id,	-- creation_user
			:parent_id,			-- context_id
			:creation_ip,		-- creation_ip
			'content_item',		-- item_subtype
			:content_type,		-- content_type
			:title,				-- title
			:description,		-- description
			:mime_type,			-- mime_type
			null,				-- nls_language
			:data,				-- data
			'text')				-- storage_type

Weird.... that a good 3 hours of jumbling the params, recompile pg driver, etc.

Collapse
3: Response to cr/cms feature list (response to 1)
Posted by Dan Wickstrom on 08/11/02 04:04 PM
There are two content_item__new functions with 16 params, so it's pretty easy for pg to get confused when everything gets input as a string.
Collapse
4: Response to cr/cms feature list (response to 1)
Posted by David Kuczek on 08/11/02 04:25 PM
"Screenshots of the Editor's Tools being used" (http://www.cofax.org/site/real.jsp) are really nice...

opencms looks like a pretty mature product. Incidentally one of their main sponsors framefab.de is headquartered ~5 miles from where I live. But they don't have screenshots that let you check out functionalities at a glance...

--> We really need screenshots!!!

Collapse
5: Response to cr/cms feature list (response to 1)
Posted by Dave Bauer on 08/11/02 04:34 PM
I agree with Jun. We need several services that can be used to build a nice CMS user interface.

ETP will use just a few of these services, leaving out workflow, and using a very simple user interface. Other applications might need to use different features, or present them to the user in a different manner. One CMS UI for everyone is the wrong way to go.

So here are some services we will need to build:

Categorization: already in the content-repository. Needs work, we might want to make this a more general service to allow categorization of any acs_object.

Related Items: this is implemented in the CR, and also generally as acs_rels. We need to make sure there is an easy way for developers to tap into this feature.

Multimedia upload and management: Image management, and relating the images to content items to appear in templates. I am not sure if this is covered anywhere.

Templating per content item: this depends on the CMS implementation. The current CMS has this.

What else?

Collapse
6: Response to cr/cms feature list (response to 1)
Posted by Dave Bauer on 08/11/02 04:38 PM
Just a note: categorization needs to get a general service if we want to use it across packages. RIght now several packages roll their own, so the categories are totally seperate. We want to be able to relate categories across packages.
Collapse
7: Response to cr/cms feature list (response to 1)
Posted by Jun Yamog on 08/11/02 05:08 PM
Yes Catgorization must be site wide much like how CCM is now.  Its useful to have a single page that contains.  Articles, bboard post, etc. that are related because they have a common category_id.  So it must be moved to acs_objects level.  Of course we need a volunteer for this.

Cofax UI is fair but it sure does work for its creators KR.  Cofax is poor in developer support.  Its just too specific for its need.

DanW has posted some very good fixes for PG for CR.  I hope he gets help.

Anyway I think the first solid step is to decide what to do in general.  My opinion is to break apart CMS into simpler components.  Or what I am doing right now experimenting on building very thin packages on top of CR.  I don't think such drastic changes will go into 4.6.  I think 4.6 is more a bug fix, use PG 7.2 features if possible and for dotLRN.

Collapse
8: Response to cr/cms feature list (response to 1)
Posted by Don Baccus on 08/11/02 07:22 PM
Drastic changes won't go into 4.6, you're right.  And Lars and I have been talking about building tools to tap into the existing CMS code in a high-level way, making it much easier to write the kind of thin-layer CR apps that Jun talks about.

It would be nice if ETP played well with the portals package, BTW.  It would be cool to be able to use it to build portlets with content as well as pages with content.  That could be a lot of fun to play with.

Anyway ... I think Dave's right that one CMS-fits-all solution isn't the right way.  ETP fits one set of needs, a traditional publishing-oriented CMS with content scheduling, workflow etc a different need and the kind of tools Lars and I have talked about yet another.

The nice thing about it is that a lot of the code that's needed already exists.

I also agree about the categorization stuff.  We need a central service.

BTW the file storage datamodel incorrectly derives its CR content from cr_items rather than cr_revisions, which breaks the cr_item_rel stuff.  I think this crept in as a result of "search" but am unsure.  I'm going to put fixing that on the 4.6 todo list.