Bug 857264 - Rewrite publish system to use WebComponents for each trackevent and media#1632
Bug 857264 - Rewrite publish system to use WebComponents for each trackevent and media#1632mjschranz wants to merge 1 commit intomozilla:masterfrom mjschranz:b857264
Conversation
| for ( k = 0; k < numSources - 1; k++ ) { | ||
| mediaUrlsString += mediaUrls[ k ] + '" , "'; | ||
| for ( k = 0; k < numSources; k++ ) { | ||
| popcornString += '\n<webmaker-media href="' + mediaUrls[ k ] + '" target="' + currentMedia.target + '" ></webmaker-media>\n' |
There was a problem hiding this comment.
I wonder if there's a way for us to make the web components loadable server-side too, so we don't have to hardcode element generation.
|
I'm not sure this approach makes sense; with web components, what a user has in their client is already the code that should be published, minus whatever hosted-by-us requirements we have (like GA, etc). Making the server rebuild the page rather than having the user send over "this is my page HTML now" introduces an unnecessary step that is virtually guaranteed to rewrite what the user wants to save into something different. A better approach would be to have the client send over the serialized "I am looking at this document right now" view, and then validate->inject->store that. |
|
I agree but I think at the moment that's more effort than it's worth. Previous in the app you could view source before saving the project to the server and was removed at somepoint during the major UI redesign. I'm thinking in the future when we integrate all this into the application itself perhaps we have multiple toggle able views: Normal/Graphic, Code and Preview. All accessible before sending any data to the server which would send basically preview + our meta data + GA and whatnot. |
|
I think this is too big a difference to do in stages, but let's get some more input here. @humphd, @brettgaylor |
trackevent and media
2 participants
No description provided.