Adam Heath wrote:
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: Woop! Confluence data imported into git and displayed with webslinger!
> From:
> Adam Heath <[email protected]>
> Date:
> Wed, 13 Oct 2010 17:08:07 -0500
> To:
> Raj Saini <[email protected]>
>
> To:
> Raj Saini <[email protected]>
>
>
> On 10/13/2010 12:03 AM, Raj Saini wrote:
>>
>>> Then, with the backend code and template files stored in the
>>> filesystem, the actual content itself is also stored in the
>>> filesystem. Why have a different storage module for the content, then
>>> you do for the application?
>>>
>> I don't think it is a code idea to store your code and data together.
>> Data is some thing which you need to take regular backup and your code
>> is generally in binary form and reproducible easily such as deploying a
>> war or jar file.
>
> That's what overlay filesystems are for.
>
> /job/brainfood-standard-base and /job/brainfood-shop-base have all our
> code. /job/$clientname-$job-name then has the content for the site. We
> have an overlay filesystem implementation written for commons-vfs that
> merges all that together into a single view.
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.
