Overview of the current DAM implementation and open Issues/Questions.
- Current Implementation
- Tracking DAM copies and uses
- DAM Workspace Structure
- Concept - DAM 1.0 future improvements
Concepts to clarify
AssetProvider assembles the DamAsset based on the asset node from the workspace and the related DAM asset.
- Sets the Meta-Data source which allows for flexible changing the ways of how meta-data is fetched and from where (typically - from the asset node internals, but could be from wherever).
Stored informations on an Asset:
- mgnl:asset language Asset.getLanguage() --> returned type: String or Local ?
- mgnl:asset name Asset.getName()
- mgnl:asset title Asset.getTitle()
- mgnl:asset type ???
- mgnl:asset subject Asset.getSubject()
- mgnl:asset description Asset.getDescription()
- mgnl:asset caption Asset.getCaption()
- mgnl:asset copyright Asset.getCopyright()
Information stored in the Meta-Data content node (these are the optional properties that a content node can have)
- mgnl:content caption Asset.getCaption()
- mgnl:content title Asset.getTitle()
- mgnl:content description Asset.getDescription()
- mgnl:content copyright Asset.getCopyright()
- mgnl:asset attributes are not exposed by the Asset Implementation (language/title/...). Is this correct?
- Meta-Data: Should we keep the concept of a MetaData object?
- copyright is this not a Asset attribute ?
- how to handle duplicate (title/description) defined on Asset and Meta-Data ?
- Should we introduce a concept of CopyRight ?
Get meta-Data from DAM asset, and override it if existing on the content node.
Remove the Meta-Data concept.
Add caption and copyright properties under asset Node.
It will be to responsibility of modules using DAM to override these properties if they come from another place (STK, textImage model class)
Asset Node Type
Current DAM workspace hierarchy structure:
- Version: How to handle versions?
- For external provider we said that we should at least have one DAM Node pointing to the external Content (binary) but
Should we introduce a new type for external Content ?
In addition from previous concept page:
- 'Although assets could come from different sources, the asset node will have standard fields that will enable it to be displayed in lists etc'
- 'AssetNode has a field specifying assetProviderType'Not Implemented
- For multivariant assets (i18n-ed, multiple sizes etc.) it might support multiasset
mgnl:multiasset) this way we could potentially group assets that should be presented as one within Magnolia, but still allow each variant to keep own set of properties and be indexed separately.
Still How to handle version?
Keep the current JCR structure.
MultiAsset, ExternalAsset will be better defined in another SPRINT.
Asset Provider functionalities
Extend the Asset provider functionalities:
- getAssets(Node, String) List<DamAsset> : If the Identifier refer to a DAM folder, return the list of child assets
- In previous STK/DMS collaboration - link to a document can be a path or a Identifier. Do we support path?
- Currently in info.magnolia.dam.asset, there are Asset, DamAsset, and DamAssetWrapper (And considering there is no more metadata)
(Im not talking about stk AssetWrapper here)
- Do we really need Asset and DamAsset - why, is this just an artifact from DMS?
- What is the value of DamAssetWrapper
Only support Identifier link to DAM.
Review the current DAM API
- Remove DamAssetWrapper
- Rename DamAsset to InternalAsset
Links (related to MGNLSTK-1048 issue)
Create a DAMURI2RepositoryMapping extends URI2RepositoryMapping (Equivalent of DMSURI2RepositoryMapping)
Create a DAMDownloadServlet (Equivalent of DMSDownloadServlet)
These two class should use the DAM class to get the correct AssetProvider. The AssetProvider should expose a method getLink(damNode) --> String tha return the correct Link based on the source storage (dam workspace, webdav...)
DamAsset ? should we keep this class?
Should we create an equivalent of DMS document?
Should we remove or deprecated all STK dam package?
STKImagingSupport should use only STKTemplatingFunction to create Link for Binary content and not TemplatingFunction.
In STK for model class that use previously DMS, we expose a method that return the target as ContentMap. This content map is the representation of a JCR node.
How to handle external source ?
Should we return an Asset object instead? --> review and migrate FTL's
- Taken approach : Deprecate old methods. Expose a new method returning an Asset.
STK Model still expose method like getDMSDocument. Should we rename these methods --> review and migrate FTL's.