Hi Samuel,
First of all, I could not check all links you shared here. Sorry about
that. But I rather to get back to you sooner than wait until get more
time to read all them =)
My only concerned about that is how much gain a Web developer will have
with this Wok framework/library comparing to Bootstrap or other existing
technologies.
Wouldn't we attract more people if we use existing technologies on which
Web developers are already familiar with?
What are the benefits of having our own UI framework/library? Would it
be simple enough to be an entry point for Web development?
Regards,
Aline Manera
On 06/03/2016 11:00 AM, Samuel Henrique De Oliveira Guimaraes wrote:
Hi team,
After the open discussion session on our last scrum meeting regarding
Wok as an UI framework / library, I decided to list some alternatives
and technologies that we could use on the next releases or Wok 3.*.
The idea is to provide a solution that allowed developers to create
panels, tabs or even full plugins with minimal or no knowledge on HTML
and CSS or even DOM manipulation with jQuery.
Instead of using default HTML tags, the developer could write
something like this for Kimchi network tab for example:
<wok-panel collapse="false" title="Networks">
<wok-datatable filter="network.name, network.interfaces,
network.address, network.type" model="kimchi.networks"
sort="true"
sort-by="network.name" actions="network.actions">
</wok-panel>
<wok-window model="network.add">
...
// Network modal window contents
...
</wok-window>
<wok-window model="network.edit">
...
// Network modal window contents
...
</wok-window>
This might seem too ahead of time but in fact it looks like any
current MVV JavaScript framework. So here are the current alternatives
with pros and cons:
1 – Custom elements API:
https://developer.mozilla.org/en-US/docs/Web/Web_Components/Custom_Elements
Current support:
http://caniuse.com/#search=custom-elements
<
http://caniuse.com/#search=custom-elements>
Status: Draft
Effort: minimal
In my opinion based on current structure this would be the least
difficult alternative to adapt current code into a library but browser
support is an obstacle.
2 – Google Polymer
https://www.polymer-project.org/1.0/docs/devguide/feature-overview
Current support:
https://www.polymer-project.org/1.0/docs/browsers
Status: Stable
Effort: medium
To work like the example above it would require some time to develop
and I think it would create something bigger than an UI library, check
an example source code and you will see what I mean. For some native
components such as form controls it would redundant. It could be
developed at the same time we maintain the current code.
3 – AngularJS
https://angularjs.org/
Current support:
https://docs.angularjs.org/guide/ie
<
https://docs.angularjs.org/guide/ie>
Status: 1.5.x Stable, 2.0 in development
Effort: medium to high
This would definitively work like the example above and make Wok and
all its plugins work like a seamless single page application (no more
problems with global variables / tasks when switching tabs from
different plugins) but the effort would be medium to high. Legacy code
would be incompatible, we would have to drop or move almost everything
that we have done with jQuery and rewrite ALL tabs, widgets and API
calls and all libraries that we currently use would have to be updated
to an AngularJS-like compatible version (or some could go away as
Angular provides native mechanisms that we could use). The advantage
here is that there’s a library that uses Bootstrap SCSS so our UI
assets wouldn’t discarded and the users wouldn’t notice anything. The
negative factor is that we would have to rewrite our code to meet
“AngularJS way”: creating services or factories for the REST calls,
directives for the UI and the logic would go to the controllers. It
wouldn’t make the developers lives any easier, in fact it would
require a narrow and specific skillset. For example: to make Wok load
plugins, we would have to write a mechanism to lazy load our plugins
dynamically based on the files installed in the plugins folder.
We could also benefit from some NodeJS plugins for unit, performance
and UI tests, even mock objects when developing new UI when we don’t
have the exact system environment, not having to worry about messing
with host or VM settings.
3 – Facebook React
https://facebook.github.io/react/
Current support:
https://facebook.github.io/react/docs/working-with-the-browser.html
Status: Stable
Effort: maximum
We would exchange HTML to JSX and JavaScript. I think based on our
project structure it brings the worst points from Google Polymer and
AngularJS analysis.
Regards,
Samuel
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel