I tried the latest code from [1] and created branch [2]. Tried it by applying a new theme and writing few new units.
Overall experience with this componentize web app is good. Easy to learn and most importantly it addresses the main problems we are trying to solve. Let’s revise the problems we are trying to solve with this. A - We need a way to reuse a certain functionality developed for one web app to be shared. B - The UIs are not consistent among different products. We need to enforce this by providing a base theme and letting each web app override it and create it’s own theme. C - Way to avoid complex DOM manipulation. D - Different teams use different 3rd party plugins and different ways of using them, hence leading to different user experiences even they are good in there own space but leaving the whole platforms ux bad. (A) ,(B), (C) is addressable by a successful jaggery UI framework. But for (D) we need something like PrimeFaces showcase. [4] Where developers can pick code snippets and best ways to deal with different use cases. http://www.primefaces.org/showcase/ui/ajax/basic.xhtml One of the arguments we had on the discussions was, “Why aren’t we going with an existing solution?”. Simple answer to this is “There is no solution that directly address our problems.” From the many technologies out there, I picked “JSF, Facelets” base solution to evaluate since it seems to be the most promising and they call Facelet composite components as reusable UI components. But they are just xhtml files with reusable logic. Created an example web app for evaluation [3]. It simply reads a text file with api names and expose them in a RESTfull web service, and display it using Managed Beans, Facelet templates, and Custom components. Jersey is used as the JAX-RS reference implementation. Main drawback I see in this approach is there is no direct support for HTML5 tags. We have to create custom components for each new HTML5 tag. Then there is Angular JS. Which also looks promising. But there are many drawbacks. I tried to list down the things I saw as plus points and negative points with the table at the bottom. It's not completed but can use to visualize the good things we can have with the new Jaggery UI framework. Following are the improvements I think should be there in the new Jaggery UI framework. - Possibility to inject many units to a single zone. - Menu system needs to support grouping/ multiple levels and should be more flexible. - There should be a way to treat UI plugins as dependencies and control the order of there injection. ( For example jQPlot depends on jQuery and jQplot requires js files as well as css files ) - Unit can be expendable. [1] - https://github.com/manuranga/xstore [2] - https://github.com/manuranga/xstore/tree/new_theme [3] - https://github.com/chanaka3d/wso2ui/tree/master/jsf_facelets [4] - http://www.primefaces.org/showcase/ui/ajax/basic.xhtml Angular JS Pure JSF, Facelets JSF, Facelets with Primefaces Polymer Unit Reusable UI components. Yes Provided with “Directives” Yes Provided with Composite Component - Is a template - Have validators, converters and listeners attached to it - Is a combination of other components - Have an interface and implementation - Is a xhtml page Same Yes Provided with Unit. Unit is a collection of js, jag, json files which will push a certain view and backend logic to the application. Component Extending Can write a composite component who uses other composite components Same Not available Learning curve Average ( will be a stiff one for backend developers) Stiff. - Complex expression language - Lots of JSF core tags to familiarize - Bean and bean scopes Same Very easy to learn Client side dependency Management This can be done with Bower. Bower need nodejs, npm and git. Ex: "dependencies": { "angular-mocks": "~1.2.x", "html5-boilerplate": "~4.3.0" } There is no way to do this Not available Look and feel 100% flexible 100% flexible Stuck with old jQuery UI 100% flexible Debugging Client side debugging via firebug Server side debugging with any IDE Same Only client side debugging HTML5 Direct support Since the main source type is xhtml each new html5 tag needs to have it’s own custom component. Same Direct support Browser compatibility Since most of the processing is happening in the client side, there will be lot of compatibility issues. There will be less client side coding comparatively. Hence will reduce the browser compatibility issues. Same Less client side issues since unit is an entity in jaggery side Security XSS Data binding Easy two way data binding Easy two way server side data binding via managed beans. But client side (ajax) data binding will mess things up and will end up writing lot of js code and dom manipulations. There are workarounds like combining with Angular. Same Not available Template Language Angular Expressions are similar to js expressions. {{ quantity * cost }} Expression language has a steep learning curve Same No template language Development style Save and refresh Change build and deploy Same Save and refresh Testing Unit Tests - Karma running jasmine e2e tests - Protractor MyFaces, JUnit Not available Dependency management Not available Build tool Grunt -( Complex and slow ) Maven On Sun, Jul 13, 2014 at 9:05 PM, Manuranga Perera <[email protected]> wrote: > Summary of what has been discussed so far on $subject > > *Features* > > *Self Contained Units* - Each with backend logic / HTML / routes > > *Unit Composition* - Create new units out of existing ones > > *Declarative manifestation* - Units can specify where it should appear > (as opposed to composition) > > *Separated layouts* - Bootstrap compatible HTML layout with placeholders > for Zones that units can appear > > *Unit intercommunication* - A Unit can manipulate input data of any other > unit in the system. > > > *Implementation * > > Each unit is a combination of following > > *Controller* - a javascript file. get executed when the http URL is > requested, if the given Unit appears in the page. creates the viewmodel (a > json data object). > > *View* - a jag file. renders HTML when the execution reach the > placeholder in the layout. use the data in the viewmodel to get dynamic > data. > > *Association Logic *- a javascript file. gets executed for every request. > responsible for pushing data to other units. > *Definition* - a json file. specifies the routers and zones the current > Unit will appear > > > > > Fig 1 : execution flow of a page that has one unit (X) in a web app that > has three Units (X, Y , Z) > > > > > -- > With regards, > *Manu*ranga Perera. > > phone : 071 7 70 20 50 > mail : [email protected] > -- Chanaka Jayasena Senior Software Engineer; WSO2, Inc.; http://wso2.com/ email: [email protected]; cell: +94 77 785 5565 blog: http://chanaka3d.blogspot.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
