J. Wolfgang Kaltz wrote:
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 ?
No, actually I mean the syntax of the string value. Just some
possibilities for the wf state:
authoring
workflow://pubs/default/config/workflow/workflow.xml/states/authoring
or for variable values:
is_published:true
is_published = true
is_published=1
I mean the workflow component has arbitrary options to encode the
meta data values. This knowledge has to be restricted to a single place,
which is the component itself. IMO this implies that the attribute names
should not be exposed by the API. People would examine the storage syntax,
parse the values and run into trouble when updating to another version
of the component which uses another storage syntax. IMO exposing the
attribute names as public fields suggests that they're meant to be
accessed by client code.
[...]
First, I think the workflow history should be separated from the
metadata, IMO these are 2 separate concerns, which we should deal with
separately.
+1, I'm working on that.
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.
I don't really understand that. Maybe it's clearer to look at
LenyaMetaData.WORKFLOW_VARIABLE_VALUE
That is not a plain string and would need a special syntax (see above)
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) ?
Yes, workflowable.getState() is better. But I disagree to
LenyaMetaData.STATE for the reasons stated above and below.
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)
I agree to plain strings, but I disagree to the centralized attribute
name management.
- no encapsulation of storage details (attribute names and value syntax
are maintained by different components)
- extending or changing the meta data set needed by a component
requires to change the core
- it's not possible to add further components which use meta data
storage without changing the core API
Actually I see components as additions to the core. IMO the core
is everything in o.a.lenya.cms.publication. Access control, workflow,
site management etc. are components which use the core functionality.
It should be possible to extend Lenya with additional components
which use the same mechanisms like the ac, workflow etc. components.
My point is: We should not provide special fields for workflow, ac
etc. if we don't provide them for additional components. A component
should be able to use the meta data in a convenient, namespaced way
without changes to the core API.
We'll run into trouble when we think like this. We're building a
framework, which needs a powerful infrastructure for implementing
components using and extending the provided functionality. Centralized
meta data attribute names lead to a lock-in.
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)
IMO that's not the way encapsulation should be applied. You don't
encapsulate data sets used by a variety of components, you encapsulate
components with specific responsibilities. Meta data handling makes
a good component, but meta data attribute names do not, unless they
serve a very specific, generally applicable purpose and are used for
data exchange (like DublinCore for publishing issues).
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
