Gregor J. Rothfuss wrote:
J. Wolfgang Kaltz wrote:
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 also think that the answer tends to be no, which in turn means it is a
piece of cake to make these attributes into jcr properties
+1
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)
seems to me to be a difference whether the knowledge about attributes
should reside centrally in LenyaMetaData, or decentrally with the
various components. each has their strengths, but until we have very
loose coupling between lenya components, i don't see much harm in having
this knowledge centralized.
I think we're on a good way to achieve loose coupling, and IMO that's
one of the most important issues re. maintenance and extensibility. And
de-centralizing meta data attributes is another step in this direction.
I see the MetaDataManager as a service which offers the functionality
to store meta data which are needed by other components. If the MetaDataManager
exposes a fixed attribute set, we'll have to change the core API whenever
we change a component's meta data set.
Assume you're implementing a component needing several meta data attributes
in a publication. If you're using the CustomMetaData, you're running into
several problems:
- risk of name clashes, especially if you're using the pub as a template
and add further components
- you have to implement your own namespacing syntax to avoid name clashes
- making the component available to the public can also lead to name clashes
IMO we should not separate between LenyaMetaData and CustomMetaData, but
we should offer each component to use its own meta data set.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
