Working with Composite Components

AppSymphony provides four distinct component types:

• base
• constant 
• parameter
• composite

Base, constant and parameter components are implemented directly in the underlying code. But composite components contain one or more flow diagrams that you can compose to meet your specific needs.  Composite components allow you to package or 'abstract' potentially complex / highly detailed functions with specific inputs and outputs into distinct component blocks that can be reused across many applications. 

Furthermore, you can compose composites inside composites inside other composites – there’s no theoretical limit how deeply they can be nested.  As a practical matter, usefulness and compute memory will limit how deeply you can actually nest composites.

Composite components are essential to provide modularity and structure to your apps.  Without them, you would end up with apps that have very large messy diagrams.  Not that AppSymphony knows or cares if diagrams are messy - it will save, retrieve and (try to) execute any apps and components you give it.  However, a key benefit of AppSymphony's graphical flow diagrams is their ability to quickly and efficiently capture and convey which information work an app/component does and how it does it.  Thus any attention paid to component structure and diagram 'neatness' pays substantial dividends in terms of understandability and efficient reuse. 

There are three types of composite components:

• simple composites - contain exactly one diagram
• higher order templates - contain one template diagram + one composite diagram
  • map, fold, filter, each, do while, zip, unzip
• case - contains one diagram for each case