Hallo,

Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

The meta-data approach sounds intriguing, that would definitely make the "Topics" thing work well. I am still wondering how much people will be willing to learn the "plone way". Most people are lazy, so you have to give them a compelling reason to learn something new. So that's generally why I advocate making things work in more 'standard' ways. The "plone way" is nice, but what's most important to me is that people use the site, so that's why I always bring up these annoying questions :).;

Questions and discussion are what I wanted to provoke with my Topics action ;)

It's not only the Plone way: Most decent content management systems collect low level content by hand, but provide higher level views ("news of last week", "10 best tracks",...) automatically. That's a big part of the "management" task in "CMS". Editing the overview pages by hand will soon lead into total chaos. I have seen that too many times, that's why I strongly encourage to use the tools at hand. Yes, managing 12 tracks by hand is possible, but managing 120 isn't anymore.

I like to compare the "Topics" and similar tools to Makefiles: Of course one could simply call a compiler 23 times by hand, but Makefiles make this task so much easier and less error-prone by using rules for repeating tasks.

The most natural thing would be to create content types called "track", "patch", "external source code", that people could add to their folders like a news item. But sooner or later we will end up with a kind of markup for our custom content types. That's exactly the place, where the Keywords come in. And even custom content types would need to be collected somehow ==> Topic.

With Topics and Keywords, it also is no problem to have content appear at more than one place. Maybe someone has a patch, that is part of a tutorial but also a composition, like for example Miller's 'composition' with data structures in the html-docs.

Such a patch could just get two Keywords: "composition" and "tutorial" and would appear at both Topics.

The other way would be to automatically create overview pages for the content of just a single folder. But this requires every member having write-permissions for that folder or would mean a lot of file-moving or link-copy'n'pasting to the editors. By keeping the content items inside their home-folders and just collecting them, we can organize the workflow roles, that stood at the beginning - like Reviewer, Manager, Member - much easier.

To get to your usability question: Maybe a good explanation of how to set Keywords would suffice, but later, when some of us are more intimate with Plone, we might want to write custom forms for submitting patches, tracks and so on. For example, a user that wants to submit a track should just get an upload form with some text fields for description, title,.., but the Keyword "Tracks" could be added automatically.

We'll need to document how to use pure-data.org... another thing on the ToDo list...

Yes, for sure. I'd prefer Wikipages for that. I'll start some soon. But we also have to decide on how to organize such things before getting the documentation of it out.

I already did a small change again: I removed the requirement, that Tracks have to be of Type "File". So now there could be intermediate pages, that describe a track in more detail and maybe also link to the patch, that the track was done with.

EOF

ciao