parser: support auto loading?

[wkeese]

The parser doesn't do auto-loading anymore, mainly because:

• its asynchronous nature breaks the API of document.createElement("d-tree") and our sister function register.createElement("d-tree")
• auto loading doesn't match the web components spec
• it's more complicated than before since there's not an obvious mapping between tag name (ex: <d-tree>) and the widget (ex: dui/Tree or dtree/Tree or ...)

But we could support it by have each package provide something like an AdapterRegistry that would map a given name like d-tree to a widget definition if that package provides the widget, or return undefined otherwise.

At a minimum though the app would need to register each package w/the parser, which somewhat defeats the goal of being automatic.

A related issue is auto-loading of widgets declared in templates. That again though breaks document.createElement("d-tree") since it's supposed to be synchronous

[cjolif]

Just brainstorming, but maybe an alternate "solution" would be to consider this a pure build task. The build would look for the dependencies based on configuration (d-treeamp = ..., d-whatevher = ...), build a layer for the app, and make sure that layer is loaded before parsing the DOM. @clmath, opinions?

[wkeese]

I'm not sure what problem you are trying to solve, compared to the solution I listed in the original ticket description.

I thought the point of auto-load was for rapid application development, which contradicts having to do a build.

[cjolif]

Right. As I said I was just brainstorming and trying to see if we can manage to avoid this and in the process I forgot about the initial goal. So nevermind...

[cjolif]

Ok. Another try ;)

As we are planning to provide our various projects also as built layers and advertise them as a way to easily build apps. Those built layers could do the registration of the various widget they contain. That way in order to do:

<d-container>
   <d-button></d-button>
   <d-calendar-week></d-calendar-week>
   <d-calendar-day></d-calendar-day>
</d-container>

one could just do something like the following loading the layers:

require(["dcalendar/dcalendar", "deliteful/deliteful"]);

instead of each class individually:

require(["dcalendar/CalendarWeek", "dcalendar/CalendarDay", "deliteful/Button", "deliteful/Container"]);

That said:

1. This is not full auto loading as the layers needs to be loaded
2. This won't work for people not using the layers
3. This lets open the question of the (a)synchronicity

The more I think about this the more it looks like we will spend a lot of time on that and we do not necessarily have a lot. Maybe it will make sense to delay that to a second release if we really want it (with the risk that the choices of the first release makes this impossible to be implemented layer). In which case #28 would also be pushed away. Opinions on "closing" this for now?

[wkeese]

Hmm, well that's certainly the simplest solution. The only downside is pulling in a bunch of widgets you don't want.

The basic idea of setting up a registry mapping tag name (ex: d-button) to widget (ex: Button) seems fairly simple, but I suppose once we do that, users will also want a build step to automatically create their layers depending on what widgets they are pulling in... so perhaps it is best to keep things simple for the first release, and defer this ticket.

[wkeese]

one could just do something like the following loading the layers:

require(["dcalendar/dcalendar", "deliteful/deliteful"]);

Those built layers could do the registration of the various widget they contain.

Actually, the layers already do that, by calling register() for each widget they contain. But now we are no longer talking about auto-loading, but rather manual loading.

Anyway, I'm closing this and #28 as wontfix for now. Given that we are leveraging native custom element support (in browsers that support it), and thus leveraging the brower's built-in "parser" to find the widget elements, I don't think it's practical to do auto-loading.