I have two use cases in mind: 1. Components which use images (most likely SVG) for skinning. The components would reference their own internal files by default, but would probably allow the end user to specify their own graphics instead for custom skinning.
2. A library which includes graphics that would allow developers to use the graphics by reference (i.e. some kind of manager class or something as simple as a constant which would resolve to the correct url location). In either of these cases, the compiler wouldn’t (and shouldn’t) do any magic, but the component set might in certain cases create HTMLElements that use the assets. > On Jan 7, 2020, at 7:56 PM, Josh Tynjala <joshtynj...@bowlerhat.dev> wrote: > > As a developer, I would expect to create my own image element in > ActionScript code and reference the appropriate URL based on where the file > was copied. I wouldn't want the compiler to add an <img> to my HTML > template. It would feel too much like magic and probably wouldn't be > configurable enough to be useful. > > -- > Josh Tynjala > Bowler Hat LLC <https://bowlerhat.dev> > > > On Tue, Jan 7, 2020 at 9:51 AM Alex Harui <aha...@adobe.com.invalid> wrote: > >> >> >> On 1/7/20, 9:33 AM, "Harbs" <harbs.li...@gmail.com> wrote: >>> On Jan 7, 2020, at 7:28 PM, Alex Harui <aha...@adobe.com.INVALID> >> wrote: >>> >>> I would think any of these files need to be loaded by some other >> code. They can't just sit in the output folder. >> >> True, but this problem is smaller for image files which can simply be >> referenced in the app (the src in an HTML app). As long as the relative >> path is predictable, this issue is manageable. >> >> I might just be too nit-picky, but I think even an image needs a >> HTMLElement in the DOM. So any class that wants to have an image copied >> into the output folder needs to either run code to insert an <img> tag in >> the DOM or have the post-process somehow know to add an <img> tag into the >> output .html file and since the position of <img> tags really matter >> specifying position in the annotation would be painful, IMO, so I would >> expect class code to insert the img tag. >> >> Order of loading CSS and JS matter as well, but hopefully it will match >> class initialization order so we don't have to define order in the >> annotation. >> >> Class code is generally required because Royale does not put an initial >> DOM of HTMLElements in the output html file. All HTMLElements are added to >> the DOM by code (or by inject_html, but not in any particular order). >> Teaching the compiler to construct an initial DOM and have the class code >> find the DOM elements (I think JQuery sort of worked this way) would >> require a different component set and two initialization paths in the >> components ("find the element", and "add the element") so Basic does not >> try to support that. Some other component set could, but because we want >> to encourage dynamic, state-based UX I'm not clear there would be >> significant advantages. In Alina/Pashmina's app, for example, the initial >> DOM would just be a login screen. >> >> -Alex >> >>
