1、1,Dive into GridX,May 8th, 2012,2,Agenda,Capability Highlight for Enterprise Scenario,GridX Overview,Discussion - Marketing Position,3,GridX Overview,4,A fast rendering, well modularized and plugin architecture based GridGridX is consisted of A compact and lightweight core A flexible plugin machiner
2、y with comprehensive module life-cycle and conflict management A rich and extend-able set of modules which can be loaded on demand.Targeting Enterprise Scenario with optimized capability for Dealing with huge data store Compatibility among rich and complex modules Leveraging fast increasing new requ
3、irements in the future,What is GridX?,5,Fundamentally address key limitations of the existing Grid Redundant and complex internal logic that makes it: Painful to add new features, “hack” needed most time Very easy to brings new defects when fixing the existing issues Duplicate rendering that downgra
4、de performance Incapable of supporting more than 50,000 rows in virtual scrolling mode(#11446) Increasing memory when used with huge data store(#11370)Provide a flexible plugin machinery that can support fast increasing new requirements in the futureReach a reasonable balance of “Fast”, “Small” and
5、“Flexibility”,Design Rationale of GridX,6,Covered most features in existing DataGrid/EnhancedGrid Feature & API stabled, defect fixing still in progress Major focus till v 1.0 GA: TODO Supported browsers Regression fix, doc & tutorial Performance tuning More complete A11Y & i18N support,GridX Latest
6、 Status V 1.0 Beta,7,GridX Feature Matrix V 1.0 Beta,8,9,Capability Highlight for Enterprise Scenario,10,GridX Capability Overview,After optimized, GridX has following capabilities to deal with Enterprise Scenario Fast rendering speed and minimal UI refreshing times. Flexible module machinery with c
7、omprehensive module life cycle and conflict management Nice modularization and much easier for extending more feature modules. A new refined scroller that provides better scrolling experiences Capable to support unlimited number of rows in both virtual scrolling and pagination modes(100 million+ row
8、s) Stable memory usage even if a user keep scrolling to go through a huge datastore for a long time. IBM OneUI Standard compliance More easy-for-use API signatures Lazy rendering huge children rows in TreeGrid Rich feature coverage and ease for upgrading Kept pace with Dojo 2.0 evolving path pure ba
9、seless, AMD, dojo.on, dojo.has etc. Targeting a high level of module mutual compatibility Targeting a high level of IBM I18N & A11Y,11,Systematical module life cycle management Logical module dependency Module loading sequenceMinimized conflicts with module-specific API namespace,1 - 1. Flexible Mod
10、ule Machinery (cont.),Render header,Logically depends on,NestedSort and HeaderFilter should only be initialized after Header finish rendering so its Not a static file dependency This kind or more complex logical dependencies are not covered by AMD require(),/ modules.RowLock API grid.rowLock.lock(ro
11、wIndex); grid.rowLock.unlock(rowIndex);,/ modules.ColumnLock API grid.columnLock.lock(columnIndex); grid.columnLock.unlock(columnIndex);,- Dont need to worry about func naming conflict, and more easy to know “where do the API come from?”,- Very helpful since all plugin API are dynamically added/remo
12、ved on demand,modules.NestedSort,modules.HeaderFilter,modules.Header,12,Module dependency, load sequence or conflicts are transparent to users Modules can be used in any arbitrary orders“Real” plug-able modules By keeping the same Module.name (e.g. “vScroller”), any module can be replaced without af
13、fecting all other modules depending on itselfPotential capability to support flexible and fast increasing requirements Benefits not obvious in simple scenario but will become important with increasing requirements in the future,1 - 2. Flexible Module Machinery,Even if there were complex mutual depen
14、dencies, modules can be used in any orders.,Depends on,The three VScroller modules can be switched freely without affecting any other modules depending on them.,13,API and UI are kept as clean/separated modules for UI features e.g Pagination + PaginationBar, Filter + FilterBar Adaptable for increasi
15、ng and changing requirements UI modules can be replaced or switched flexibly for various requirements Ensure a maximized reusability and stability No matter how UI module changes, the corresponding API modules are stable and reused,2. UI & API Separation,Stable API module,modules.Pagination,modules.
16、PaginationBar,UI module,modules.PaginationBarDD,Another Pagination UI Impl,Pagination Feature,Can be safely switched,14,Scroller is separated from body content More flexible control on body viewport Row rendering logic is decoupled from virtual scrollingAll grid rows are now in native adjacent struc
17、ture No need to continuously setting the absolute position any more which was also a factor affect scrolling speedUnneeded rows are removed in an asynchronous way which nicely improves scrolling performanceThe previously known joggling issue in the existing Grid scroll bar is also solved,3-1. New Sm
18、art Scroller (cont.),15,Fundamentally addressed the total size limitation of Grid(#11446) GridX can now support unlimited number of rows (e.g. 100 million+ rows) in virtual scrolling mode An optimized mode for scrolling huge dataset - “lazy scrolling” Scrolling is held off until user really finishes
19、 scrolling Greatly reduced obsolete data fetching requests to store (server-side) Significantly improves rendering speed even when user keep scrolling across a huge dataset Much better scrolling experience No blank view during scrolling (assuming good network when with server-side stores) Scroll bar
20、 will also be very reliable no matter how the row height changes Extending flexibility e.g. Possibility for future OneUI style scroller TODO OneUI scrolling bar,3-2. New Smart Scroller,16,The caching machinery can ensure a configurable max threshold of item number on client side Even a user keeps sc
21、rolling to go through the huge data set for a long time, the memory usage will still be stable. Addressed the long known limitation of the existing Grid(#11370) TODO Olivers input/snapshot on CacheCapable to deal with huge data store (100 million+ rows) With the new scroller and optimized rendering
22、way, GridX can now support unlimited number of rows in both virtual scrolling and pagination modes TODO snapshot/test with for a real 100M test case,4. Optimized Capability for Huge Data Store,17,Two important targets of GridX Rich feature coverage Minimize upgrading effort for existing Grid usersGr
23、idX V 1.0 Beta covers most features in EnhancedGrid/DataGrid and brings convenience for upgrading The existing EDG/DataGrid users dont need to worry about dropping any existing features by upgrading to GridX Also besides traditionally key features like Native concept of row index Scroll to an unload
24、ed row position by indexGridX never stops equipment itself with more cool features (e.g. the experimental Detail-on-Demand and Row-Lock modules),5-1. Feature Coverage & Ease for Upgrading(cont.),18,GridX provides a very compatible and similar usage as the existing EnhancedGrid/DataGrid,5-2. Feature
25、Coverage & Ease for Upgrading,DataGrid / EnhancedGrid Usage,GridX Usage,Similar usage makes it easy for upgrading,19,One key mission of GridX is to be compliant with IBM OneUI Standard (Grid part) GridX OneUI theme/features will be delivered with IDX - idx.oneui.gridx Though idx.oneui.gridx wont be
26、available externally, the whole GridX project might evolve in a roadmap to better support OneUI. TODO more OneUI Grid snapshots, progressbar issue fixes,6. IBM OneUI Compliant,20,GridX is targeting a high level of module mutual compatibilityBecome more challenge with increasing new requirements rais
27、ed,7. Module Mutual Compatibility,GridX v 1.0 Module Compatibility Matrix,21,Though still in progress, GridX targets to reach a high compliant level with IBM i18n & a11y standard A flexible and extendable keyboard management is well integrated with GridXs module machinery The whole viewport of GridX
28、 is divided into different view areas TAB / Shift + TAB is used to navigate among these view areas A UI module can register itself to a certain view area during initialization Module-specific keyboard navigation principle will not affect other view areas,8. A11Y & I18N Compliant (in progress),Filter
29、 Area,Header Area,Pagination Area,Body Area,TAB Key Navigation,TAB/SHIFT + TAB to navigate among view areas LEFT/RIGHT key used to navigate within a view area,22,GridX loading & rendering speed with 100, 10,000 and 1,000,000 rows Compare with DataGrid/EDG/ dgrid same feature, simple and complex,6. B
30、enchmark TODO move to a better position,23,TreeGrid is implemented as a module in GridX and can be loaded on demand Key improvements Can lazy render both root and nested children rows Improved rendering speed even if used with a tree store of huge nested rows. Support both Normal and Nested Expando
31、modes and much easier for switching More reliable UI, e.g. wont collapse when refreshed TODO, Oliver to add more More handy API e.g. programmatically (recursively) expand/collapse a node,7. TreeGrid (Experimental),24,Target to provide a native mobile grid that has minimized mobile-specific logic as
32、well as mobile-oriented features & experiences. No extra desktop-related logic to keep as small and fast as possible. In an early phase starting from a most simple version in v 1.0 Only with UI rendering, sort and touch scrolling features Can be integrated and run well with dojox.mobile.* Future pla
33、n more features coming based on IBM OneUI Mobile Standard (Grid) Consolidated requirements from products TODO snapshot from Nate,8. MobileGrid (Experimental),25,Complicated rows(colspan/rowspan) are not supported. DnD Row module now changes data store directly so its not compatible with SingleSort a
34、nd NestedSort ColumnLock/RowLock can only lock leading or trailing columns/rows (leading only in v 1.0) DnD Cell is not supported Cell merge is not supported Performance tuning still in progress for using CellWidget /AlwaysEditing pervasively in viewport. Performance & memory usage testing still in
35、progress for huge data stores TreeGrid only supports lazy rendering children rows, rather lazy loading children rows (children data will be fetched at one time, though they will still be lazy rendered in UI) TreeGrid is still experimental and only compatible with limited modules I18N and A11Y suppor
36、t is not finished and still in progress,GridX v 1.0 Known Limitations,26,Discussion Market Position,27,Much effort has been spent on converging dgrid and gridx, but not successful due to different design rationale and targeting requirements.Discussion held in Dojo Community reaching the agreement to
37、 have two parallel grid projects.,Previous Dojo Community Discussion, Is there a compelling reason as to why the two codebases need to be merged? Whats wrong with the idea of having two grid implementations, each focusing on specific needs/wants? , It seems to me from what communications Ive seen th
38、us far, that dgrid and gridx have somewhat different goals in mind , In other words, theres nothing wrong with having two (or more) implementations where each learns from the other, and makes their own better for it ,28,GridX has a different segmented market scope Focusing more on Enterprise Scenari
39、o (Complex & fast increasing feature, huge dataset etc.)GridX more suitable for IBM products use due to Optimized capabilities for Enterprise Scenario Better complaince with IBM OneUI Standard Support channel for adding new features, fixing issues etc.Discussion Follow up actions Reach a consensus with community on GridXs different segmented market scope and host a promoting site externally on Dojo Foundation ? Or focus our limited energy on best serving IBM product usage?,GridX Market Position - Enterprise Scenario,29,
