So how this is going to work one code is deployed inside a application server? For example as a war or ear or let us say inside the component folder of OFBiz?


Here is an example of what I mean by overlay:

==
doo...@host:/job/brainfood-standard-base/pages/BASE/www/account$ tree
.
├── Actions.whtml
├── left.vm
├── left.vm@
│   └── no-edit
├── Menu.whtml
├── newsletters
│   ├── Header.whtml
│   ├── index.groovy
│   ├── index.groovy@
│   │   ├── is-filter
│   │   └── require-login
│   ├── List.vm
│   ├── SuccessMessage.whtml
│   ├── Title.whtml
│   ├── View.vm
│   └── View.vm@
│       └── no-edit
├── password
│   ├── index.groovy
│   ├── index.groovy@
│   │   ├── is-filter
│   │   └── require-login
│   ├── SuccessMessage.whtml
│   ├── Title.whtml
│   ├── View.vm
│   └── View.vm@
│       └── no-edit
├── profile
│   ├── contact-action-EMAIL_ADDRESS.vm
│   ├── contact-action-POSTAL_ADDRESS.vm
│   ├── contact-action-TELECOM_NUMBER.vm
│   ├── contact-edit-EMAIL_ADDRESS.vm
│   ├── contact-view-EMAIL_ADDRESS.vm
│   ├── contact-view-POSTAL_ADDRESS.vm
│   ├── contact-view-TELECOM_NUMBER.vm
│   ├── index.groovy
│   ├── index.groovy@
│   │   ├── is-filter
│   │   └── require-login
│   ├── Title.whtml
│   ├── View.vm
│   └── View.vm@
│       ├── no-edit
│       └── PageStyle
└── Title.whtml
doo...@host:/job/brainfood-shop-base/pages/SHOP/www/account$ tree
.
├── contactmech
│   ├── index.groovy
│   ├── index.groovy@
│   │   └── is-filter
│   ├── PostalAddress.vm
│   └── TelecomNumber.vm
├── destinations
│   ├── index.groovy
│   ├── index.groovy@
│   │   ├── is-filter
│   │   └── require-login
│   ├── NotYetCreated.whtml
│   ├── Orders.vm
│   ├── RelationDisplay.vm
│   ├── Rename.vm
│   ├── Rename.vm@
│   │   └── no-edit
│   ├── Title.whtml
│   ├── View.vm
│   └── View.vm@
│       └── no-edit
├── order
│   ├── Actions.whtml
│   ├── index.groovy
│   ├── index.groovy@
│   │   ├── is-filter
│   │   └── require-login
│   ├── Print.vm
│   ├── Print.vm@
│   │   └── no-edit
│   ├── View.vm
│   └── View.vm@
│       └── no-edit
├── orders
│   ├── index.groovy
│   ├── index.groovy@
│   │   ├── is-filter
│   │   └── require-login
│   ├── NoOrders.whtml
│   ├── View.vm
│   └── View.vm@
│       └── no-edit
└── paymentmethods
     ├── index.groovy
     ├── index.groovy@
     │   ├── is-filter
     │   └── require-login
     ├── Title.whtml
     ├── View.vm
     └── View.vm@
         └── no-edit
doo...@host:/job/content-site/pages/CONTENT/www/account$ tree
.
├── destinations
│   └── View.vm@
│       ├── PageStyle
│       └── section-Left
├── Menu.whtml
├── newsletters
│   └── View.vm@
│       ├── PageStyle
│       └── section-Left
├── order
│   └── View.vm@
│       ├── PageStyle
│       └── section-Left
├── orders
│   └── View.vm@
│       ├── PageStyle
│       └── section-Left
├── password
│   └── View.vm@
│       ├── PageStyle
│       └── section-Left
├── paymentmethods
│   └── View.vm@
│       ├── PageStyle
│       └── section-Left
└── profile
     └── View.vm@
         ├── PageStyle
         └── section-Left
==
You'll note that standard-base and shop-base have different account
folders.  base has completely generic screens, while shop has screens
that only make sense for online shopping sites.

Then, the content folder has the same directories that exist in both
of the bases, but is very light-weight, and only sets certain
configuration parameters.

All three of these directory structures are then merged at runtime, to
provide a unified view.  A higher-level tree can add new files, or
replace files.  It's also possible to delete a file in a lower level;
the standard term for this is called a whiteout.

Each main top-level folder(/job/foo is the root) is a separately
maintained git repository.

This has allowed us to share code between all of our sites, so that
features and fixes can be rapidly deployed, while allowing the
customer's content site to only contain what is required to configure
the bases.


Reply via email to