Support for Creating Variants on Demand#7
Conversation
… needed when we generate new variants in the context after we process the initial variant tree. This is very early support and does not deal much with error check and fallbacks such as what happens when the parent source is not available. We also do not use media hints for different things such as the persistence adapter
There was a problem hiding this comment.
I think this method would not need particular customizations for each provider type.
Probably we should move it to the main MediaStorage class.
There was a problem hiding this comment.
I was thinking that as well however we have to create a local temp directory and we don't have access to the providers temp path.
|
Hi @mtotheikle! |
3 participants
This is initial support for what will later become lazy loading of variants I imagine. This also solves a use case of wanting to render media after the variant tree has been process and the files are stored on some filesystem. It becomes difficult to process a new variant later because we are not dealing with a filesystem that is local so we must get a copy of the file that will be the parent and create a temporary file on the local system that will be used as the initial to create a new context from. We may also want to update variants due to design changes such as the width and size and we should not have to re-upload the original and process the full tree again.
This is in early stages, but wanted to create a pull request for feedback and regarding thoughts/roadblocks that may occur. I am also looking to start a conversation on abstracting some of the processing logic out of MediaStorage as this class is acting as a God class and currently doing a lot of work... Other pull request may be started based off how that goes.