Andreas Hartmann schrieb:
Hi Lenya devs,
I came accross the following issue:
Currently, Lenya supports 3 types of meta data:
- LenyaMetaData
- DublinCore
- CustomMetaData
LenyaMetaData should be used for "internal" meta data.
The problem here is:
Which class is responsible to know the attribute names?
Actually IMO only the component which actually uses the meta
data should know the attribute name, and it should encapsulate
them. Otherwise we present an option for misuse:
String state = metaData.getFirstValue(LenyaMetaData.STATE);
This is bad code, because the syntax of the state storage
is known only by the workflow components.
IIUC by syntax you mean the way workflow state knowledge has presently
been represented in XML ? For example
<wf:history xmlns:wf="http://apache.org/cocoon/lenya/workflow/1.0";>
<wf:version date="2005-06-03 18:25:58" event="submit" state="review">
<wf:variable name="is_live" value="false"/>
</wf:version>
</wf:history>
First, I think the workflow history should be separated from the
metadata, IMO these are 2 separate concerns, which we should deal with
separately.
If we want to consider the current workflow state as metadata of a
document (which I agree makes sense), this is a separate concern than a
state storage syntax. In this particular case, IMO we should "flatten"
the current state knowledge in the Lenya metadata, so something like
<lenya:internal>
...
<lenya:workflowState>review</lenya:workflowState>
</lenya:internal>
So, the code which accesses the current state does call
metaData.getFirstValue(LenyaMetaData.STATE), but needs no further
knowledge about state storage. Whereas the component which presents
workflow history uses different code.
> It should rather read
Workflowable workflowable = new DocumentWorkflowable(document...);
String state = workflowable.getLatestVersion().getState();
Could that not be "workflowable.getState()", which would in turn call
the document's metaData.getFirstValue(LenyaMetaData.STATE) ?
I hope I am not completely misunderstanding something; I noticed there
were changes this week in trunk regarding workflow & metadata handling,
but I have not yet been able to keep up with them.
As a general design strategy, my opinion is:
LenyaMetaData is Lenya's specific metadata about a document - meaning,
all metadata not clearly standardized in Dublin Core. IMO it makes sense
to put all metadata pertaining to the document in this container. This
does not say which component "uses" it; in fact we cannot predict future
uses. Any component wanting to use this metadata must know its name and
access it via the LenyaMetaData. This generic "metadata = simple
attributes" approach does, I agree, imply that arbitrary, nested XML is
not possible within the metadata. So the decisive question is, do we
really need such XML within the metadata ? (IMO no)
To summarize, IMO it is in fact good code to encapsalute (non-DC)
metadata within LenyaMetaData, including the name of the attributes, and
any component needing access does something like
metaData.getFirstValue(LenyaMetaData.WHATEVER_ATTRIBUTE)
Any issues other than getting current meta attributes about a document
should not be handled via the MetaData interfaces.
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
