Hi Manu, You have listed down the required features well. Let me add two none-functional requirements and prioritise them accordingly. 1 - Performance - The UI must be responsive and should not take long to load 2 - Usability - The framework must be easy to grasp for developers and should be easily debuggable
And here is my priority. 1 - Componentization 2 - Layout separation 3 - Declarative population 3 - Performance 4 - Usability 5 - Ability to plugin authentication mechanisms Arbitrary overriding and inheritance are good to have things and should not hinder any of the above requirements such as performance or usability. thanks, dimuthu On Mon, Dec 22, 2014 at 7:18 PM, Manuranga Perera <[email protected]> wrote: > In new UI framework we have proposed following features. there were some > concerns about the complexity of the framework due to these “advanced” > features. In this thread I would like to go through each feature and > discusses why we need them. please contribute your ideas on the usefulness > of each feature. > > 1. Componentization > > UI is made out of components that are self contained. this mean each > component has it’s own CSS/JS/ backend code/HTML it needs to render the UI. > This is the basic feature of the framework. > > > 2. Layout Separation > > Layouts lives separately to the UI. here layout means the basic structure > of the UI, fluid/non-fluid , number of columns, banner and footer placement > etc. > > 3. Declarative Population > > some UI elements (eg: menu) is populated using the information that is > gathered from multiple components. EG: there is no single file that you > can open and find out the structure of the menu, each components pushes > individual links that makes up the whole component. > > usecases > > - > > left side navigation menu like in carbon console UI > - > > in top navigation bar, cloud needs to add additional links > - > > tab views for AM needs documentation tab additionally > > > > 4. Arbitrary overriding > > any part of the UI (granularity depends on implementation) can be > overridden without directly changing the code of that section. you add a > new component and defined what part you should override. > > usecases > > - > > Logo needs to change from product to product > - > > UI Action needs to change depending on device type/RXT type in > publisher/CDM > - > > Customers need to add sections to header/footer or body. > > > 5. Inheritance > > when you override a component (as in feature 4), you can reuse the > overddin code and just override a part of it. this allows re-use among the > overridden and overriding components. (like extending a java class but only > overriding few methods) > > usecases > > - > > If you are overriding the asset view and change the “Subscribe” button > to “Install” for a given asset type (eg mobile app) then you should > rewrite the whole code section that renders the item description. > > > > - > > If you add a new theme for AM that extended grenic store theme you > shouldn’t write it from the scratch. the customers should then be able to > extend it and create their own. > > > WSO2 Generic theme -> Generic Store Theme -> AM Store Theme -> Customer > Store Theme > > > > -- > With regards, > *Manu*ranga Perera. > > phone : 071 7 70 20 50 > mail : [email protected] > -- Dimuthu Leelarathne Architect & Product Lead of App Factory WSO2, Inc. (http://wso2.com) email: [email protected] Mobile : 0773661935 Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
