Here is a set of recommendations for using Olympe in a most effective manner.
One of the defining characteristic of Olympe is that it has been built for reusability and scalability from the ground up. Therefore, software engineering best practices can be applied.
Gartner: "A tool for fusion teams"
Business - IT continuum, for business and IT to work together to solve the need of customers (and they HAVE to work together) It's an Integration Tool: integrate different systems/technologies/features together --> solution to heterogeneity & to multiplication of apps
Catalog / marketplace just a way to support the composition. Added value is the ability to extend the catalog. Applications no longer monoliths, but sets of bricks Adapt by composing / recomposing all the time
Architect the application from the top - down
Design by Contract
Design by Contract is a software design approach that recommends building formal interface specifications for software components.
This is exactly what happens when designing bricks: logic bricks have a name and a set of inputs and outputs, visual components have properties and events. Those define the contract that the brick must follow. That contract is helpful in several ways:
- Before implementing the brick, one can use it in different situations to make sure that its contract makes sense. Do we have the right inputs/ouputs? Will I be able to use it?
- The contract allows alignement between different members of the team, which is particularly useful when building fusion teams with both business and IT expertise.
- While implementing the brick, the contract ensures that behavior of the brick is well defined. This is particularly important if the actual implementation is performed by someone with potentially less functional understanding, e.g. in a nearshore development team.
DRY - Don't Reinvent Yourself
Bricks are meant to be reused. Useful functionalities can therefore be used multiple times within a given project, or even reused for across different projects.
Reuse bricks across multiple projects
POINT TO HOW TO REUSE A BRICK ACROSS MULTIPLE PROJECTS
Bricks by essence encapsulate a set of functionalities. It is therefore recommended to have well defined bricks rather than having large components providing a mixed set of functionalities.
Test visual components and logic bricks
POINT TO HOW TO BUILD A SMALL APP TO TEST A BRICK
Refactoring & MVC
Like in traditional programming it is very common to attach logic directly to visual components. For example we may put all the logic directly on the On Click of the button. This can be made more modular, maintainable and reusable by wrapping the logic within a brick, which is then called when clicking on the button.
Extract logic from a component
POINT TO HOW TO USE PROMOTE
Split a visual component into smaller pieces
POINT TO HOW TO USE DUPLICATE, REFINE, REPLACE
Check where a component is used before refactoring
Use Groups for layouting
Vertical, horizontal, mosaic, spacing
Static formatted text easily provided using some HTML/CSS rather than by concatenating multiple labels and other visual components.
Show Alert Dialog are examples of bricks that support raw HTML/CSS content. Other UI bricks also support some degree of customizability via their
PUT SOME SCREENSHOTS
One can build a library of reusable texts using Enums. This can be used to define common JSON strings for use in e.g. API calls, or to be reused in popups, error messages and labels. Wrap it into a brick to provide a nice editor.
Dialogs and popups
Different bricks depending on use case:
- Show Alert Dialog / Confirm / ???
Use Data Types
User multiple applications
Makes it easier to serve different types of users (e.g. main app + Admin App for data loads, reporting, configuration, tweaking stuff without giving access to DRAW)
UI vs. Functional refactoring
promote vs. duplicate & erase