Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Add upload to the Asset Browser.
  • Create the Provider Registry
  • Add provider options (from the registry) to the Asset Browser.
  • Use Case: have two different dam workspace provider instances to the Asset Browser.
  • Extra Credit: s3 or dropbox provider

 

DAM Concept Proposal (old and mostly implemented, here - for tracking)

The main conceptual changes from DAMSupport in 4.5 are:

  • DAM/DAMSupport will not handle direct binary uploads to a content node. The default behaviour of all STK components will be to use assets in the dam. If a direct binary upload to a content node is desired, the "upload field" control can be used instead of a "dam field" control. (A new STK component would need to be created which contained this field.)
  • A content node in a website will contain just one value to reference the DAM Asset, the identifier (UUID) of the Asset. Previously there were two values, one specifying the type of DAMHandlers, another containing either the identifier of the dam node, or the binary content. The DAM Asset node itself will store what type of assetProvider it uses.

New names:

  • DAMHandlers => AssetProviders
  • DAMSupport => DAM

Concept:

  • There is a DAM module where all code is stored. (Except necessary STK integration)
  • Content node has a field which is the identifier of the dam asset node.
  • AssetNode has a field specifying assetProviderType.
  • An AssetProvider registry enables the system to use the proper AssetProviderType for an Asset.
  • Although assets could come from different sources, the asset node will have standard fields that will enable it to be displayed in lists etc.
  • Nodes are of type mgnl:asset (nt:file) as this is the standard jcr type for dealing with binary assets. In the case that the node itself references a remote binary, the required jcr:content child node will be populated with minimum required content.
  • Multi-Site:
    • AssetProviders are not aware of different sites. 
    • On a multisite system, the sites can configure the root directory exposed by the AssetsApp. This way - each site could pull explicitly from a sub directory in the "dam" workspace.
      • The AssetsApp provides the AssetChooser which is opened from within the page editor - so this configuraration of the root directory for the assets app would also be reflected in the AssetChooser in the page editor.

Could have an externalImageProvider where you can put a url for any image - and it just imports it locally.

 

 

Notes

 
Asset Renditions

  • Create a copy of an original
  • Create a usage of a copy
  • Show uses - all content items that use an asset.
  • Behind the scenes
    • A mechanism that links usages, copies, originals
    • A mechanism that links an original and a copy
    • Usage must store its parameters
    • Copy should probably store parameters
  • (Notes: Usages - do not show up in tree. Only Original and Copy.)

Questions


  • I really cannot edit or replace an asset once it is used? Why not?
    • No. From Pascal, could lead to problems / inconsistencies. Please confirm
  • Why can i revert to original - for a copy, which updates uses - but i cannot edit that copy once it has uses?
  • Image Variations in the imaging module vs renditions

Answered Questions


  • Originals and copies can be moved and named independently of each other. But they always retain the (hidden?) link.
  • You can edit an original (does not automatically create a copy).