aurelia-ui-toolkits / aurelia-kendoui-bridge Goto Github PK

To reproduce try typing 2 characters on the "Basic Usage" test page.

The second character usually appears after the autocomplete has updated the input field.

For example type "ch" and the input will complete with "charlesh"

This task asks for a detailed analysis of questions raised in this article

Please provide the answers in that same article

Note I assigned this to Charles as he "owns" the grid component that uses HTML compiler in his own private implementation of grid

This is a place-holder for a lot more comprehensive task of integrating all KendoUI controls with Aurelia Validation

Not sure whether this is related to Aurelia Dialog!

Given the accepted classification of KendoUI controls into two groups

• native HTML controls
• controls that do not have HTML native implementation

we have the rule which determines whether a control will become a custom element or a custom attribute.

While we already have the first KendoUI control - AutoComplete implemented using Aurelia custom attributes, this control is not the generic representative of KendoUI controls that is converted to Aurelia component - meaning that the autocomplete cannot be used as a template for processing the rest of KendoUI controls.

DropDownList adds more complexity as we need to create the children DOM elements - probably form an array of strings, using Aurelia HTML compiler -- and I would prefer to see Charles define the code for all such cases (including the controls that are not HTML natives like Grid).

There are several important issues:

• use Aurelia "production" compiler or the private branch Charles uses today
• definition of the utilities folder (to me made, with compiler being the first inhabitant)
• ...

that are all better to be decided by Charles

Pay attention to integration with other KendoUI controls!

Looking at Telerik's TabStrip documentation I just got reminded that we have to support both declarative and programmatic style to define controls. The current implementation seems to be ready to handle both style, so in order to demonstrate that the code in the tabstrip folder needs to be augmented to match the features shown on the original demo

Seeing this screenshot raises the question that I am really curious about: having done the Aureliaization of the KendoUI tabstrip, is the Loading content with AJAX even relevant in this context - or (as I hope) this comes as a side-effect of having this control "converted" to Aurelia control?

I made the problem report here

davidpurkiss writes

I think something that should be discussed sooner rather than later is the current support that Telerik provides for web components with KendoUI.

http://docs.telerik.com/kendo-ui/webcomponents

Personally, I've been avoiding the issue as that means I need to now understand, intimately, how web components work. Over the last few weeks as my understanding of Aurelia has grown and having had a chance to play around with building custom elements properly, I feel like this is now less of a task.

Off the bat, I've come across this article and this aurelia issue. So it sounds like the Telerik web components are based on Polymer's implementation of custom elements which means we will never be able to use them with Aurelia (unless your bring Polymer into Aurelia, which sounds undesirable), which I don't think is really an issue. At this point I don't know yet, perhaps someone else has some insight?

For me the more important question is, should we be basing our implementation on Telerik's web component implementation. In other words, ideally I would copy and paste some sample from the KendoUI documentation into an Aurelia app and it just works.

I guess the TL:DR of the issue is, how do KendoUI components fit into this project?

In my opinion, we should allow the consumer of the plugin to load only a subset of our plugins. Why globalize all resources when you may only use one widget?

It would look something like this:

aurelia.use
      .standardConfiguration()
      .developmentLogging()
      .plugin("aurelia-kendoUI", (config) => {
        config.useWidgets(["button", "grid"]);
      });

this would only globalize resources for the "button" and the "grid".

• the _initialize function is called from bind (only when there are issues, attached() may be used)
• bindable properties are sorted alphabetically
• there is a recreate function
• Available API methods are proxied in the wrapper (such as enable)
• All samples found on Telerik's website are recreated using our wrapper (example)
• changed events of bindable properties are handled, only if there is an API method available. For example, the kEnable property of the button has an API function (enable()), so the kEnableChanged() function should call the enable() API function

• the _initialize function is called from bind (only when there are issues, attached() may be used)
• bindable properties are sorted alphabetically
• there is a recreate function
• Available API methods are proxied in the wrapper (such as enable)
• All samples found on Telerik's website are recreated using our wrapper (example)
• changed events of bindable properties are handled, only if there is an API method available. For example, the kEnable property of the button has an API function (enable()), so the kEnableChanged() function should call the enable() API function

• the _initialize function is called from bind (only when there are issues, attached() may be used)
• bindable properties are sorted alphabetically
• there is a recreate function
• Available API methods are proxied in the wrapper (such as enable)
• All samples found on Telerik's website are recreated using our wrapper (example)
• changed events of bindable properties are handled, only if there is an API method available. For example, the kEnable property of the button has an API function (enable()), so the kEnableChanged() function should call the enable() API function

I would love to take the first whack at this one as it is an important part of the future project I would like us to do - Aurelia Workflows :-)

• the _initialize function is called from bind (only when there are issues, attached() may be used)
• bindable properties are sorted alphabetically
• there is a recreate function
• Available API methods are proxied in the wrapper (such as enable)
• All samples found on Telerik's website are recreated using our wrapper (example)
• changed events of bindable properties are handled, only if there is an API method available. For example, the kEnable property of the button has an API function (enable()), so the kEnableChanged() function should call the enable() API function

The development guide specifies that conventions should be avoided if possible as Aurelia allows customisation of these conventions.

Any plugin making an assumption about conventions can fail when those conventions are changed

Does this apply to @bindables? I don't think it does - I prefer the convention based approach as it keeps the @bindable near the property description:

export class MyClass {
    @bindable myProperty;
}

It's also possible to decorate the class

@bindable({ name: 'myProperty' })
export class MyClass {
}

Which is preferred? Do we need to be consistent?

Using the AutoComplete Implementation Alternatives wiki page based approach, write the code that implements the following two controls:

1. KendoUI AutoComplete control

This control is a member of "Input Control Family" so its implementation based on Aurelia Custom Attributes

2. KendoUI Grid control

This control is a typical example of KendoUI control that us not a member of "Input Control Family" so it should be implemented as Aurelia Custom Element.

These two controls should be written as carefully as possible, so that just the comments that need to be present can be used as a "developer's manual". - so that anyone joining after these two components are fully written, could pick any other KendoUI control and work on it without having to ask how does this or that work

Important note

Please finish the Development Protocol article (starting here before / in parallel with coding these first controls, so that you can make references from that article into relevant code sections (to be used as examples of a specific rule in the Development Protocol

This of course needs to be consolidated with Aurelia's own. The open question is what to really do in situation where there is Aurelia's own feature that competes with this toolkit's control

Rather than collecting all discussion items from previous discussions about this, let me try to just define the requirements.

• As cloned from Github, the application consuming the plugin services should simply work without any changes.
• It is assumed that the user who wants run the app with KendoUI PRO bits, has the PRO license and all files that have to present in the vendor folder and has enabled the "run the PRO version" flag (this could be done by uncommenting the relevant line somewhere).
• Everyone on this team should download KendoUI PRO trial version and thus be able to use it in lieu of the "real" PRO version.
• This proof of concept should support both loading all KendoUI components in one fell swoop (kendo.all.min.js) or any combination of files representing single controls.

Here are some relevant links

how to use kendo-ui professional with jspm
Using Kendo UI with RequireJS