On Jan 10, 2015 8:22 PM, "Senaka Fernando" <[email protected]> wrote: > > > > On Sat, Jan 10, 2015 at 8:19 PM, Senaka Fernando <[email protected]> wrote: >> >> Hi Manu, >> >> Does the layout aspect allow someone to build two or more views for a single UI component (i.e. Handhelds vs. Ordinary PCs)? Also, though this is non-functional, should we formally define some conventions for styles, fonts, logo sizes etc? >> >> Hi Dimuthu, >> >> Shouldn't performance be the #1 priority? Shouldn't we start by setting some acceptable performance standards and ensure these are always met? > > > I mean apart from the UX aspects of the components themselves, which perhaps is not a concern from a framework PoV.
Would your team use if it is really hard? How would you convince the team? In addition I would not argue on performance vs. composability as both are very important. Thanx Dimuthu > > Thanks, > Senaka. >> >> >> Thanks, >> Senaka. >> >> On Fri, Jan 9, 2015 at 11:40 AM, Dimuthu Leelarathne <[email protected]> wrote: >>> >>> 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, >>>> Manuranga 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 >>> >> >> >> >> -- >> >> >> Senaka Fernando >> Solutions Architect; WSO2 Inc.; http://wso2.com >> Member; Apache Software Foundation; http://apache.org >> >> E-mail: senaka AT wso2.com >> P: +1 408 754 7388; ext: 51736; M: +44 782 741 1966 >> Linked-In: http://linkedin.com/in/senakafernando >> >> Lean . Enterprise . Middleware > > > > > -- > > > Senaka Fernando > Solutions Architect; WSO2 Inc.; http://wso2.com > Member; Apache Software Foundation; http://apache.org > > E-mail: senaka AT wso2.com > P: +1 408 754 7388; ext: 51736; M: +44 782 741 1966 > Linked-In: http://linkedin.com/in/senakafernando > > Lean . Enterprise . Middleware > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
