Jörn Nettingsmeier wrote:
Andreas Hartmann wrote:
Jörn Nettingsmeier wrote:
what i do care about is stopping people from ever again introducing
multi-dimensional, semantically overloaded metadata tables (!) with
built-in extensibility (!!) represented as single strings (!!!)
without so much as a passing regard for documenting this whole pile
of shit anywhere, and then having to use (shudder!) regexes to clean
up the mess.
workflowVersion in its current state is an abomination unto $deity
and must die.
fast.
violently.
Actually I don't really understand this concern. The workflowVersion
meta data are accessed only by the workflow engine, they are strictly
private and I see no need for applying any regular expressions on
them. If you need workflow information, ask the workflow engine ...
take the case of a "last modified on...by..." footer. that's probably
the most basic cms feature than i could think of. it is currently not
possible with lenya.
That should be provided by the WorkflowModule.
this information *must* absolutely be available on a cocoon level,
either as from an input module or a generator or both. talking about
writing custom java code for this every time i need it is just ridiculous.
Sure, it should come out of the box.
my starting point to achieve this goal was the LenyaMetaDataGenerator,
which was written by a seasoned contributor to lenya, so i figured that
this was the most obvious and consistent way to get at the data i need.
No, this would be the wrong way. Unfortunately the generator publishes
the workflow meta data, which should be avoided. We could introduce
private meta data, or maybe it would be better to introduce a whole
new concept, e.g. internal document properties. But this would make
the code more complex.
of course i could gather the data from all over the place, but that
would make things even more inconsistent. as it is now, every document
has its own metadata. that's nice and should remain as it is. all i'm
asking for is that this metadata is structured, documented and handled
in a sane way.
if, as you say, the workflowVersion data is private and encapsulated,
that's even less of an excuse to have all that substring() mayhem in the
getter functions (see
java/org/apache/lenya/cms/workflow/DocumentWorkflowable.java#getVersions).
Why is that bad? The DocumentWorkflowable is the single entry point
for workflow version persistence. It can use whatever format it likes.
basically all i want the metadata generator to do is spit out the
contents of the metadata xml file. of course that file is
implementation-dependant, so i can't just read it, but still the data
should be all in one place internally.
They should be provided by the respective component. In the case
of workflow, the meta data are just a simple way to persist
document-related information.
There's no point in specifying the workflow meta data, because they
might change, and every workflow engine might use its own meta data
format.
there is no point in specifying things because they might change? by
that reasoning, the entire w3.org website is obsolete by definition.
You're right, so please remove the first part of my last statement :)
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
