[Pdweb] Tracks as Topics

[Frank Barknecht]

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
-- 
 Frank Barknecht                               _ ______footils.org__