Hi Alex, ok, I understand now. You propose to do something like we do for Application but for Modules using the same kind of process but instead of adding to html head create a new .js to be added like _deps,js. I think that will be ok and even more efficient since all is done by compiler. I'll try to imagine how I can do that in the compiler. The only special case I can see is if we have the same Class in Application already, so compiler will put that link or script tag twice, one for App and again for each module using it.
Thanks El mar., 2 jul. 2019 a las 7:18, Alex Harui (<[email protected]>) escribió: > > > On 7/1/19, 9:42 AM, "Carlos Rovira" <[email protected]> wrote: > > > So, inject_html in a module should do effectively the same thing, > except I > > don't think a module needs to inject HTML, > > > right, we don't want to do that will defeat the module's purpose of > deferred loading. And moreover, we don't know which classes will have > in > the module to be loaded, or a module can be never loaded > > I don't understand why we don't know which classes will need to be loaded > before the module. The inject_html tells us, doesn't it? > > > it can just take a list of urls to load as Script tags. So, no > scanning > > of files is necessary. > > > The user could explicitly set the urls to load, but that seems to me > not a > Royale solution. I as a user, expect to use a Class that represents a > JS > library, and it should handle under the hood the necessary setup. I > have > clear that is needed to make a good solution. > > What I am proposing is that someone does modify the compiler to detect the > inject_html in the module classes and generate a .JS file you can load like > the _deps.js file. Upthread I pointed to where the code is to be > modified. If you do not want to make those changes, you can hand code the > .JS file for now. > > > HTH, > -Alex > > -- Carlos Rovira http://about.me/carlosrovira
