Polymer / WebComponents

Editor's Notes

1. 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.
2. 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.
3. First, let’s discuss our UI history… Because we are facing constraints and requirements for building an UI over time...
4. 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.
5. Current JSF2 view demo
6. 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.
7. AngularJS example
8. 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.
9. 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.
10. -> Web Components Standard; not yet finish
11. Custom Elements; Create own tag / elements; and follow them suit. (emboiter)
12. 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.
13. 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.
14. HTML Imports is intended to be the packaging mechanism for Web Components, but you can also use HTML Imports by itself.
15. 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.
16. Customelements.io and builtwithpolymer.org + Behaviors + Utility Helper
17. Why did we want to change for a new UI? Let’s see what has been our first approach.
18. That was the old screen in JSF
19. Now the new one
20. 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.
21. Still in its infancy (as shown by the logo on the top right)
22. 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:..
23. web-component-tester: wct-local: WCT plugin that enables support for local browsers via Selenium
24. In order to maintain those elements, we had to focus a long time on the QA part.
25. 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...
26. So we have this little story.
27. 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.
28. 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
29. 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
30. 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