Shadow Assets

(Nic Hubbard) #1

I am looking into the possibility of creating a shadow asset to be the child of a custom asset I am working on. I am trying to understand how shadow assets are created, and how they are allowed to be created without a real asset id, but using 200:v1 asset numbering. Are there any specific assets that can be used as an example?


I guess I am just wanting to understand what needs to go into creating a shadow asset. Some of the current code for shadow assets seems fairly complex and I didn't think that was needed in order to create a simple yet usable shadow asset.



Thanks.



Edit: Does creating a shadow asset have something to do with bridge.inc?

(Daniel Nitsche) #2

sq_shdw_ast_lnk is where the magic happens. The LDAP bridge and the DB Data Source both use them, so that would be a good place to start looking. In both cases, these assets rely on an external data source to provide the data about that asset.


However, "200:v1" is the how images reference their varieties – you may need to provide some more info. because Shadow Assets seem unnecessary for what you've described. As far as I can tell, Image Varieties are just attributes of an Image, so you might want to look at sq_ast_attr_val.

(Greg Sherwood) #3

sq_shdw_ast_lnk is only where the links between shadow assets and real assets are stored. You don't need to worry about that table at all as it is all handled for you by the asset map and asset manager. What you do need to do is implement the Bridge class and provide asset management functions like getAsset and getChildren. Use any of the current assets that implement bridge as an example. As Dan says, LDAP Bridge is a good example.

(Nic Hubbard) #4

Thanks Guys,


No, I didn't want to create an image variety, I had just used that as an example for a shadow asset but didn't mean anything by it.



What I am trying to do:



For the MP3 File asset that I worked on. I would like to have the album artwork extracted from the .mp3 file as be usable as keyword. Initially this sounded fairly simple. I wrote the image file to the data directory of the .mp3 file, which worked well. But I ran into problems when the .mp3 file was not public or live, because then the image file within the data directory didn't have a private URL, because Matrix didn't really know about it. There are also issues with things like force SSL, cloning that artwork file when the parent .mp3 file is clone, etc. All of these things can't be done (at least I couldn't figure it out) without the image file being some sort of asset and letting the file system know about it. That way I can get a private URL, things like SSL will be handled for me, and I can add the clone function so that the artwork will be cloned also if the .mp3 file is cloned. This would also solve the problem of not being able to link something like an image file under another file parent.



So, my solution was to use a shadow asset, similar to an image variety, but obviously not really the same. The artwork would be extracted, but the user wouldn't be able to make varieties of it, nor upload a new copy. It would just automatically create the artwork shadow asset when an .mp3 file was uploaded, as long as there was indeed album artwork in the file.



So, now that I have explained the whole thing, would using a shadow asset be the best solution in this case?



Thanks guys.

(Daniel Nitsche) #5

If you take a look at how image varieties work, Matrix copies the files from:

    data/private/assets/image/[4 digit directory]/[asset_id]/varieties/variety-name.png
    data/private/assets/image/[4 digit directory]/[asset_id]/image-name.png


to:

    data/public/assets/image/[4 digit directory]/[asset_id]/varieties/variety-name.png
    data/public/assets/image/[4 digit directory]/[asset_id]/image-name.png


The image then stores the information about varieties as a serialised array in sq_ast_attr_val:

     attrid | type_code | owning_type_code |   name	|   type	| uniq | parameters_type_code | parameters_val | default_type_code | default_val | description | is_admin 
    --------+-----------+------------------+-----------+-----------+------+----------------------+----------------+-------------------+-------------+-------------+----------
    	699 | image	 | image			| varieties | serialise | 0	| image				| a:0:{}		 | image			 | a:0:{}	  |			 | 1


Having said all that, I would think it would be easier to create the images separately, then just link them to the MP3 asset with a value of "artwork" for example. It saves having to deal with a serialised array anyway :)

PS. as I said before, I don't think shadow assets are the right approach for what you're trying to do
(Nic Hubbard) #6

What do you mean by separately? Have the user set a create location for them? My problem is, if I create the image on upload, that image asset cannot be a child of the parent mp3 file. And, if we don't create the image file as an asset at all, how can it have a private URL as well as links?
(Daniel Nitsche) #7

Yes, separately = as an image asset, linked to the MP3 asset. You could create the asset first, then let the user add/upload the artwork, which would allow the image to be a child.
(Nic Hubbard) #8

Hmm, this does not seem very streamline and nice. The artwork is actually extracted from the .mp3 file itself, that is why I wanted it to be created at the time the mp3 is uploaded, so a user wouldn't have to do anything else....
(Greg Sherwood) #9

Using a shadow asset would be ideal and they way we would develop it here. But it will be hard and we can't really offer much general advice because every shadow asset implementation tends to be different. All we really do is reuse existing code and tweak as required. Image variety code is great to see how the URL problem was solved, but I suggest you start by just trying to get that shadow asset to show in the menu. You don't need any files for that; just implement Bridge and define some functions like LDAP Bridge does. Hard-code the values for now and get your head around how the asset manager calls your asset to ask for an object or a listing of shadow assets.

(Nic Hubbard) #10

Thanks Greg, I really just wanted confirmation that a shadow asset was the route to go. I will get to work on it!

Thanks again.