- Nuxeo has historically used different technologies for its UI such as ZPT, JSF, and AngularJS but is now exploring using Web Components with frameworks like Polymer and React.
- Polymer helps build custom elements and adds sugar to remove boilerplate from element registration, lifecycle callbacks, and observers. Nuxeo elements could provide reusable UI building blocks.
- The new Nuxeo Web UI would use the DOM as the framework and include Nuxeo elements for data and UI, layouts for convention-based dynamic loading, and testing with WCT and nuxeo-ftest.
2. Us, Ourselves and Nuxeo
https://github.com/dmetzler & https://github.com/akervern
Nuxeo | Paris / SF / NYC / Lisbon
60 people ⊃35 devs
Platform Dev + Support
https://github.com/nuxeo
11. React VS Polymer VS ….
- Set of standards: Web Components
(Custom Elements, HTML Templates &
imports, Shadow DOM).
- Polymer should just be an implementation:
our elements could be used with any
framework.
- No commitment to a framework
13. Web Components
Web Components consists of several separate
technologies. You can think of Web Components as
reusable user interface widgets that are created using
open Web technology. They are part of the browser, and
so they do not need external libraries like jQuery or Dojo.
Source: MDN
20. Helps building new custom elements
Adds elegance / Removes boilerplate
➔Element registration
➔Life cycle callbacks
➔Observers
Polymer Framework
Sugar, not magic!
21. <dom-module id="my-element">
<link rel="import" href="element-behavior.html">
<template>
<style><!-- local CSS --></style>
<!-- local DOM -->
</template>
<script>
Polymer({
is: "my-element",
// add properties and methods on the element's prototype
properties: {
// declare properties for the element's public API
...
},
observers: [],
created: () => {...}
...
});
</script>
</dom-module>
Polymer Element
ShadowDOM
Template
24. Polymer
New discovery but where do we start ?
Testing, starting but not breaking UI contributions!
Let’s override the only screen not configurable!
36. ➔DOM as the framework (+ Polymer)
➔Nuxeo Elements
◆ Data elements
➔Nuxeo UI Elements
◆ UI building blocks
➔Layouts ⇔ Custom elements
◆ Convention based dynamic loading
Web UI
48. ➔No Bower, just npm
➔ES6
➔Everything is an element
➔Build and package for deployment
Nuxeo View Designer
49. Scaffolding
➔ Full customization
◆ We can not plan for everything
◆ People already override templates
◆ Not built with that use case in mind
◆ Not that simple
➔ Runtime metamodel comes at a cost
◆ Need a simpler/shallower component tree
➔ BYOUI + Studio
Hello,
This presentation is going to sum up the platform in term of UI and we are going to see how we build currently our next future interface with Polymer and web components in general.
Nuxeo is a java platform open source editor, so all the developers are closely working with the support in order to help our customers and get direct feedback to fix bugs quickly and to reactively improve our features.
First, let’s discuss our UI history… Because we are facing constraints and requirements for building an UI over time...
Late in 2000, Nuxeo was found and was providing a platform in Python, in Zope. At this time, the HTML templating was in ZPT (Zope page templating but I won’t go into that :)) Then we had a big migration to Java, because our customers have dev teams with specific skills and we had to follow the trend. The entire code was rewritten and JSF 1.0 was chosen be part of the UI. We used freemarker as well as an alternative. JSF2.0 in 2012, little late but it was done knowing we had to change for something new and attracting for people, we returned to the client side! We had some customization in AngularJS, ReactJS, Polymer but not still for the main UI.
Current JSF2 view demo
First question, is what do we need to adress our customer needs? Which framework we can choose. Single page app is a good direction; build on top of the JS client.
AngularJS example
Im not going to compare all the frameworks. There is enough debates about this online, this is not the purpose of this conference and you will be certainly stronger than me on this part. No, by this part, i would like to tell you what we are concerned about at Nuxeo about.
First the ideal situation would be to have no commitment to the framework. We are committed to Polymer, we’re getting married to Polymer. But the most important thing for us is
To have a set of standards: the web components. To not re-invent the wheel, to get the standards. If there is a problem with polymer one day, we can register our elements, we will loose databinding and other things but we could make it in case
Polymer should just be an implementation and yes our customers will still have different skills in their dev team so we have to be general in our approach and the webcomponents are perfect for that
We have chosen polymer because we think it’s the simplest, most elegant and yes, the dataflow of reactjs is nice and lots of things are good but i can tell you i have seen presales, with no strong javascript background and they were really happy to use that. For the dataflow we could implement Flux in our side…
To finish with this short interlude, i wanted to show you this tweet of last week, by a google polymer engineer that was funny for me, but not apparently for everybody :) I don’t endorse of course with a smiley, especially the adjective siloed… but what we have to remember here is just: frameworks are paving the path for getting standards. So really all the frameworks are good and thank you guys for all this work.
Before entering into the subject of UI, I have to tell you about mechanisms, concepts of the platform… Because we are facing constraints and requirements for building our new interface.
-> Web Components Standard; not yet finish
Custom Elements; Create own tag / elements; and follow them suit. (emboiter)
Think of a template as a content fragment that is being stored for subsequent use in the document. While the parser does process the contents of the <template> element while loading the page, it does so only to ensure that those contents are valid; the element's contents are not rendered, however.
Shadow DOM provides encapsulation for the JavaScript, CSS, and templating in a Web Component. Shadow DOM makes it so these things remain separate from the DOM of the main document. You can also use Shadow DOM by itself, outside of a web component.
Why would you want to keep some code separate from the rest of the page? One reason is that on a large site, for example, if the CSS is not carefully organized, the styling for the navigation can "leak" into the main content area where it was not intended to go, or vice-versa. As a site or an app scales, this kind of thing becomes difficult to avoid.
HTML Imports is intended to be the packaging mechanism for Web Components, but you can also use HTML Imports by itself.
Before entering into the subject of UI, I have to tell you about mechanisms, concepts of the platform… Because we are facing constraints and requirements for building our new interface.
Customelements.io and builtwithpolymer.org
+ Behaviors
+ Utility Helper
Why did we want to change for a new UI? Let’s see what has been our first approach.
That was the old screen in JSF
Now the new one
Currently our UI framework depends on a metamodel and on Facelets + JSF + Seam
We want to make your job easier and provide a set of portable building blocks, little black boxes, that you can bundle in your applications (web and hybrid mobile and desktop apps)
In our current state we have a customizable a and pluggable UI but now we and something reusable and composable.
So, instead of "hammering" our UI to fit your needs you will be able to easily build your own.
Still in its infancy (as shown by the logo on the top right)
Main goals:
Iterative user-centered design (move fast, experiment, test, learn, adjust) rinse, repeat
See how far we can get with DOM as the framework. KISS
Evolve our Nuxeo Elements
Nuxeo UI Elements as building blocks (BYOUI)
Layous as custom elements
Tooling and QA
Work on Web UI was started quickly so we can do iterative user centered design. We decided to use Polymer as the framework and right now we have more questions than answers so we're tackling several challenges, like:..
web-component-tester:
wct-local: WCT plugin that enables support for local browsers via Selenium
In order to maintain those elements, we had to focus a long time on the QA part.
We come from a java ecosystem with maven, jenkins and we have discovered the JS dependencies management world with NPM 2 dependency tree issues and the version conflict with bower etc...
So we have this little story.
see here what bower-fetch is (just an Ant macro to fetch artifact from maven).
This is the script I’ve been using to package them https://gist.github.com/nelsonsilva/2c961fab4d7a326db8d6
https://github.com/eirslett/frontend-maven-plugin downloads/installs Node and NPM locally for your project, runs NPM install, and then any combination of Bower,Grunt, Gulp, Jspm, Karma, or Webpack.
As you all know Polymer released their Polymer Designer it was pretty cool, so cool that of course we couldn’t help but to build our own for the elements we were working on ;) An thus we had a first prototype of Nuxeo designer
Justin Fagnani started work on a new version of Polymer Designer for Polymer 1.0. We were hanging on the edge of our seats waiting for a first release
We asked around but apparently this has been pushed to the bottom of the backlog, where tickets go to die :P
So, we brought in a team of ninjas to build our own visual designer….
Also, since we never intended to have a full blown visual HTML editor we decided it would be good to have a go at it and build our own WYSIWYG editor for our layouts so we are now hard at work on Nuxeo View Designer
Facelet templates are heavily factorized and built around our metamodel => cleaner and easier to maintain but maybe not that easy to understand for new comers
More and more customers are building complex and specific business application
They want to build their own web application and still use Studio to configure it
