Enter ADAM 1.0
ADAM stands for Automatic DAM (Digital Assets Management). It will save your users 80% of their time when working with images or documents. Here's the reason you want it:
In most cases a user will create content (like title/text/picture) for which he'll need to upload a picture. This often takes many interactions and dialogs to select folders, upload, select uploaded picture etc. In 99% of all cases the picture is used only on this piece of content and never re-used again. So the act of organizing the storage location serves no real purpose but takes a lot of time.
Enter ADAM: The user simply drags the image from his PC to the field where he would select the image. Everything else is taken care of automatically. The user doesn't have to care where the image is, it just works.
How does it work?
The upload process uses a simple AJAX web services and stores the files automatically according to the following structure:
- ADAM Root Folder - usually 2adam
- App Folder - like Content
- Entity Folder - like L8TsNZZhRU-eScyY4bY8fQ
In this case the file would be /Portals/0/2adam/Content/L8TsNZZhRU-eScyY4bY8fQ/Logo/2sic.jpg.
Drawbacks and Shortcomings of ADAM
A core concept of this system is that the user will never have to work with this folder, because normally these files will never be re-used in any other piece of content. Because of this, these folders are not meant for browsing or selecting anything, they are also hard to guess when trying to organize files. This is on purpose.
Usability Questions
- If I upload a new file, how can I know where it's stored?
- This is automatic storage - you shouldn't care where it's stored, it just happens.
- If you really, really want to know, look at the resulting link
- My file name has important SEO-words. Do these get lost?
- No, the file name is preserved and fully visible in the link
- If I upload the same file again, does it replace the original file?
- No, ADAM will give the new file a number behind the file name to ensure it doesn't overwrite the original file.
- If at a later time the content-editor wants to use the picture in another place as well, what does he do?
- The simplest solution - which we recommend in most cases - is to just upload the image again. This is very practical - because saving the image twice is no problem for the server, and this way it's always very clear what entities rely on what content-items.
- Another simple option - but not really recommended - is to move the file to a normal folder when you decide to re-use it multiple times. This is very easy, because all content-items referred to the file as file:704 - so if you move it from within DNN, the references will still work.
- Why does it create a folder per field?
- Primarily this is to prevent naming conflicts in the asset file names
- Additionally, it's because we're also planing a future feature where a field will contain many files
- I have other preferences regarding storage structures - can this be configured?
- As of version 1.0, this cannot be configured. So if you really, really don't like it, you'll have to avoid ADAM
Technical Questions
- What is this strange, GUID-like ID used in the folder?
- It's the GUID of the content-item (EntityGuid), but shortened to 22 characters using a base64 encoding
- Why not use a number ID instead of a GUID to identify the folder for the entity?
- the number-ID can sometimes change (like when exporting/import lists of items etc.) so it would not be reliable and when copying content to another system, you could have files in folders "belonging" to another content-item
- When I export an App with all it's content-items, will it include these files?
- Yes, it will include the currently used file on any hyperlink-field. Note that it won't include other files which are not officially in use.