iks auf der ElipseCon 2011: Tickling the shoulders of giants
0 likes•1,646 views
The document discusses the challenges faced in developing a complex financial services application using Eclipse RCP, particularly in structuring UI code, defining UI rules, and managing validation processes. Key issues include structuring code for complex screens, creating efficient data binding, and establishing effective validation rules that can be reused across client and backend sides. The document also highlights the importance of quality assurance through headless builds and tests, addressing challenges related to UI testing and validation timings.
iks auf der ElipseCon 2011: Tickling the shoulders of giants
- 1. Building industry solutions Tickling the shoulders of giants An internal client for financial services based on Eclipse RCP 04.11.2011 Holger Grosse-Plankermann [email protected]
- 2. About me Holger Grosse-Plankermann Developer @ iks since 2006 Has been implementing Eclipse RCP applications for 4 years Has published articles about Eclipse RCP Likes loud guitar tunes and kitchen tools @holgergp
- 3. Challenge Areas Eclipse RCP Component Challenge Degree Eclipse Runtime SWT JFace Workbench Other prerequisites for the Workbench Test/Build
- 5. Project Form-based Business application 5.000.000 data records 5 Java Developers starting with basic RCP knowledge Project has been going for 2 1/2 years Complex problem domain ~ 400 CRs
- 6. The RCP Client Eclipse RCP 3.5 Menu View List applications Editor Area Editors similar Search View
- 7. Parameters ~ 80 screens ~ equally complex ~ 30 UI Elements per screen ~ 20 UI Behaviour Rules per Screen ~ 40 Validation Rules per screen ~ 150 different Validation Rule Types
- 9. Our context
- 10. Core Challenges Structuring code of complex screens Concise definition of numerous UI rules Considering specifics of distributed Validation Quality assurance in a complex project
- 11. Core Challenges Structuring code of complex screens Concise Definition of numerous UI rules Consider specifics of distributed Validation Quality assurance in a complex project
- 12. 1. UI Code Structure How to structure the user Interface code Standard approach: ? Define Look Define Behaviour
- 13. 1. UI Code Structure Separation of concerns: MVP Pattern
- 14. 1. UI Code Structure Split up EditorPart
- 15. 1. UI Code Structure Which part should extend from the framework :
- 16. 1. UI Code Structure Straightforward approach: View extends from the framework. Delegate logic to presenter Easy to implement/refactor Keeps integration with WindowBuilder However, too much delegation needed, complex indirection followed.
- 17. 1. UI Code Structure Presenter extends from the framework. => framework supplies lifecycle hooks. View is a standalone component. Presenter simply delegates to the createForm method of the view Workarounds needed to feed view to Window Builder Special case: Dialogues
- 18. Core Challenges Structuring code of complex screens Concise Definition of numerous UI rules Consider specifics of distributed Validation Quality assurance in a complex project
- 19. 2. UI Rules and JFace Databinding Behaviour Rules: Behaviour that is triggered when a user keys in a specific value. Mostly specific to only one Use Case Commands/Actions too cumbersome in that context
- 20. 2. UI Rules and JFace Databinding JFace Databinding for UI State definition Model „single source of truth“ Concise and central definition of bindings public void initDataBindings() { binder.bindBeanToText("model.name", view.getTxtName()); } UI Behaviour Rules should be defined similarly! No out-of-the-box solution available!
- 21. 2. UI Rules and JFace Databinding We implemented a BindableAction
- 22. 2. UI Rules and JFace Databinding Complete UI state/behaviour definition in one place in a „declarative“ and clean way public void initDataBindings() { binder = new BindingUtil(new DataBindingContext(), this); binder.bindBeanToText("presenter.gp.name1", view.getTxtName1()); binder.bindBeanToCombo("presenter.gp.anredeFachId", view.getCvAnrede()); binder.bindAction(„presenter.gp.lieferantenstatusAktiv", new BindableAction() { public void run() { clearTable(); } ); } Generation based on model easily possible
- 23. Core Challenges Structuring code of complex screens Concise Definition of numerous UI rules Consider specifics of distributed Validation Quality assurance in a complex project
- 24. 3. Validation Client Backend Time of validation On Input On Save Amount of validation Specific input step Complete Model Focus of validation Speed Complete Validation
- 25. 3. Validation Complex and deep Validation Rules
- 26. 3. Validation Validation Rules should be reused on client and backend side. Large intersection between rule types Validation Rules too complex for JFace Validation alone e.g. Validations across domain model => Tie Validation Rules to the model.
- 27. 3. Validation Using custom Validator
- 28. 3. Validation Validations attached to the model via annotations public interface IPerson { @ValidationRules( { @ValidationRule(classOfRule = NameRule.class, errorCode = "name.invalid", affectedAttributes = "name") }) void setName(String name); } Further steps: JSR-303 (Beans-Validation)
- 29. Core Challenges Structuring code of complex screens Concise Definition of numerous UI rules Consider specifics of distributed Validation Quality assurance in a complex project
- 30. 4. Headless Build and Test The complexity of our project required proper quality assurance measures Executing SWTBot Test and exporting from workbench grew too tedious
- 31. 4. Headless Build and Test Headless build and tests to the rescue! PDEBuild completed quite quick Days/Weeks Headless SWTBot more complicated ~ 4 months JUnit3/4 related issues
- 32. 4. Headless Build and Test UI Tests tend to be long running Setup UI/Product Wait for UI components to show Complete run (~ 400 tests) takes 30 – 45 mins UI Tests sometimes behave irregularly Occasional false negatives UI Timing differs between machines Focus related problems
- 33. 4. Headless Build and Test Split test suites Continuous Regular Nightly Duration ~ 5 mins ~ 30 mins ~ 45 mins # Tests ~ 50 ~ 300 ~ 400 Speed up Build Machines Continuous with SSD Continuous w/o SSD Duration ~ 5 mins ~ 9 mins
- 34. 4. Headless Build and Test No satisfying solution for irregular behaviour! UI timing issues require extra care bot.sleep(2000) mostly helps Further steps: Minimize UI related Tests Apply Controller/Presenter Tests => Eclipse Riena
- 35. Core Challenges Structuring code of complex screens Concise Definition of numerous UI rules Consider specifics of distributed Validation Quality assurance in a complex project
- 36. Safe on the shoulders of giants? Expectations Experiences Learning Out-of-the-box Requirements Eclipse RCP + Customizing
- 37. www.iks-gmbh.com
- 38. Image Sources Roadmap: http://www.flickr.com/photos/scoobay/3788514070/ Mixing desk: http://www.flickr.com/photos/go_freyer/4486482108/ Check: http://commons.wikimedia.org/wiki/File:Green_check.svg X-Mark: http://commons.wikimedia.org/wiki/File:X_mark.svg Feather: http://www.flickr.com/photos/n0rthw1nd/4418311590/ Plain face: http://commons.wikimedia.org/wiki/File:Face-plain.svg Sad face: http://commons.wikimedia.org/wiki/File:Face-sad.svg Happy face: http://commons.wikimedia.org/wiki/File:Face-smile.svg Light Bulb and Warning Icons via Creative Commons Attribution 3.0 Unported by http://shlyapnikova.deviantart.com