Fusion Design Fundamentals

Duncan Mills gave a great presentation on ODTUG regarding the Fusion Design Fundamentals which gave more insight in how to manage and start in Fusion Development.

The key take aways I found very interesting:

  • The Groundwork: 1. understand the fundamentals of the UI in which you’re aware of what ADF can and can’t do (don’t start designing in dreamweaver because you need to be able to hook it up into ADF. 2. Prototype it and make it sufficiently real which will also give your team and the customer a real case study of what the application can become. 3. Approach the framework and architecture with an open mind because the architectural approach is key.
  • What is the fusion blue print = View – Business Logic – Data (as what you would think working with an MVC-framework.
  • Educate your UI Designers: Use the Placeholder Data Control to mock data and services + show them the rea-site in which you have a sandbox available to plug and play with the different components + behaviour of the design is key when designing User Interfaces (e.g. what happens to the application when I resize the window)
  • Team organisation: a. Optimize team size so you can have expertise in specific technology areas (you can’t do that if the team’s to small, in that case they need to know more about the framework, as well UI as business logic for example). b. try to partition the skills: UI specialist, Service specialist, Orchestration Specialist, DB Specialist, SCM-build and release management. => more separation within the team so developers can specialize.
  • 2 trains of training: a. Create Subject Matter Experts that can mentor large teams (they create POC’s and get to know the framework). b. SWAT-team: mixture of architects and PM’s to get high level view of development teams and decide when to move up and escalate, e.g. in case of a bug
  • Source control and release management need a separate team in which Master Data Management is an integral part of dependency managment
  • Specific things you can do with the stack: a. Create your own Superclasses (Application Super Classes for ADF BC + UI Event Handler Superclasses). b. Use templates for the UI and taskflow using your pre-defined exception handlers. c. Use the skinning-technology to be able to change the look and feel of the UI in a general, generic way. d. Learn to love ADF Taskflows which is fundamental to create reusable stuff and to encapsulate a flow of information ( ADF Taskflow = Page flow on steriods; used for chunks of reusable UI with transactional state, private memory areas, … the true Web 2.0 experience). e. Work with the UI, not against it (think of geometry management, e.g. use decorativeBix which can be resized and stretched depending on the UI Specs) => don’t use absolute sizing or positioning. f. Document the UI patterns you’re using: e.g. master-detail, wizards, … the common patterns are documented on OTN: ADF Functional Patterns.
  • ADF 11G: You will have different source of template patterns to choose from (this is an awesome functionality in which you can choose to work with 1, 2 or 3 columns and each area can be defined upfront as being locked, stretchable, scrollable, …)

Another interesting part of the presentation, 5 laws to live by ;o):

  • Don’t write javascript because anything in Javascript can be hacked or bypassed (make use of the Client Side and Server Side Listener functionalities)
  • Don’t mix in html => stick to the components, avoid JSP Constructs (e.g. JSP include or JSTL) => in this way you can use any controller-layer possible and uplift performance
  • Minimize Use of CSS => use skinning technology and define custom styles in skin
  • Don’t write Custom SQL => try to do it declaratively using view and entity objects
  • Communicate ! Demo, document and share experiences

This was a really interesting presentation regarding the organisation of teams, how to use ADF and what the pitfalls can be.