Organization of the Aurelia-KendoUI-Bridge application

[adriatic]

One of the most strategic innovations in creating the Aurelia-KendoUI-Bridge application was to include both the "producer" (Kendo-UI-Bridge) and "consumer" (Aurelia-KendoUI-Demo) as parts of the same Aurelia application. This feature allows simultaneous work on the "producer" and "consumer" as described by this "pidgeon code"

until not finished repeat
    add a wrapper for a new Kendo control 
    write the application side code that uses this wrapper
    verify the correct behavior of newly added control

using the simplest development tools like Sublime 3 / Chrome / NodeJS.

This structure is best described visually:

The mutual relationship is however better described by the code in "consumer' applications index.html section:

   ...
   <script src="jspm_packages/system.js"></script>
    <script src="config.js"></script>
    <script>
      System.import('aurelia-bootstrapper');

      // Load the package.json from the root to get the package name
      System.import("root/package.json!").then(function(m) {
        var cfg = {
           packages: {}
        };

        // Create a new systemjs package with the package name
        cfg.packages[m.name] = {
            "main": "index",
            "dependencies": m.jspm.dependencies
        };

        System.config(cfg);

      });

    </script>
   ...

[adriatic]

Definition of a bridge and skeleton bridge

After observing reaction to my https://github.com/aurelia-ui-toolkits/aurelia-materialize-bridge/issues/1 article (which is actually an attempt to describe the "entity" I like to call bridge - an alternative descriptor for aurelia plugin used in the context of interfacing some third party toolkit) I believe that all of the above could be condensed in the following description:

Let the bridge be graphically defined as:

Image 1 - Aurelia Bridge

Then, bridge developers use the whole entity, by adding more wrapper files to the light blue box, and the sample apps that illustrate the use of the wrappers in the green box.

Creating the release of the bridge means creating the support for the users to grab only the light blue box from the repository that hosts the bridge.

Our current discussion started with the beginning of the Aurelia Materialize Bridge mainly consists of the issues related on how to create the orange/yellow box where the content of the green and light blue boxes consist of a single wrapper / sample consumer which is so generic that can be used in each bridge to verify the bridge initial functionality. At the moment, this single wrapper / consumer sample is click-counter as illustrated on image 2 below:

Image 2 - Aurelia Skeleton Bridge

The remaining task that I do not want to define yet (leaving this to @JeroenVinke as the father of the whole orange - yellow box) is the content of that box and its internal organization.

A few obvious parts are:

1. All UI elements that the green box needs at the initial use of the bridge (Image 2 above)
2. Full online help infrastructure (again needed by the green box)
3. Plugin Builder itself ... whatever else I am not mentioning here

Now, naming item 1 Bridge basic UI toolkit and item 2. Bridge Help toolkit then the orange - yellow box can be defined as shown below:

Image 3 - Aurelia Skeleton Bridge - Detailed

As it's the case with any well designed Aurelia application - all orange - yellow box sub-components are implemented as configurable `features, allow easy bridge extensibility.

[adriatic]

I used the color coded "handles" to simplify all future discussions that will follow this article

[adriatic]

It's funny to realize that all these generalization / formalizations I created with the main purpose to define the vocabulary for future conversations, the fact that our Aurelia Skeleton Bridge still remains the composition of the original Skeleton Navigation Plugin and Skeleton Plugin :-)