Fwd: Re: Woop! Confluence data imported into git and displayed with webslinger!
Locked
Fwd: Re: Woop! Confluence data imported into git and displayed with webslinger!
 
|
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. /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. |
Re: Fwd: Re: Woop! Confluence data imported into git and displayed with webslinger!
|
|
Adam Heath wrote:
> > ------------------------------------------------------------------------ > > Subject: > Re: Woop! Confluence data imported into git and displayed with webslinger! > From: > Adam Heath <[hidden email]> > Date: > Wed, 13 Oct 2010 17:08:07 -0500 > To: > Raj Saini <[hidden email]> > > To: > Raj Saini <[hidden email]> > > > 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: == doogie@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 doogie@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 doogie@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. |
|
|
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: > > == > doogie@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 > doogie@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 > doogie@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. > > |
Re: Fwd: Re: Woop! Confluence data imported into git and displayed with webslinger!
|
|
On 10/14/2010 12:53 PM, Raj Saini wrote:
> 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? The top-level ofbiz-component.xml defines the top-level webapp. The web.xml configured there then has WebslingerServlet configured, mapped to /*. All requests, for *all* hostnames, are then sent to webslinger. It has entities in the database to map multiple hostnames to a single WebslingerServer instance. There is a suffix table, that chops of domain name parts from the end, then a mapping table that takes what is left to a particular instance. There is also support for * mapping as a prefix, plus different top-level webapp context paths have their own configuration. $siteName.localhost/, $siteName.$desktopName/, www.$domainName.com/ are mapped by having 'localhost', '$desktopName' in WebslingerHostSuffix, then in WebslingerHostMapping, having '$siteName'/, 'www.$domainName.com'/ in WebslingerHostMapping. WebslingerServer then has a commons-vfs file url. We generally have it as 'file:///job/$clientName-$jobName/pages/${CLIENT-NAME}-${JOB-NAME}'. In that folder, there tends to be a www/, Config/, and Var/. www/ then as a WEB-INF/, and the rest of the content files. (we'd created commons-vfs compatible lookups for standard ofbiz 'location' urls too, ie: ofbiz-component://ecommerce/webslinger-site) The parent servlet container is *not* used at all to serve *any* files. The only thing used from the parent container is http processing, and logging. Webslinger does everything else itself. This is done by making webslinger into a servlet container; a container that can be installed into *other* containers. We call this a nested container. This has meant that webslinger's code base is rather larger than other content systems. But it allows us to install standard servlets, and still make use of the overlay filesystem feature. For instance, we have the jsp servlet installed inside webslinger, and when it needs to parse a .jsp file, the actual location of the file can come from any of a number of overlayed directories. Then, we have a git repository configured at /job/$clientName-$siteName. In there, there is the above mentioned pages folder, and as a sibling there is an ofbiz folder, that has a standard component. That is linked into the ofbiz hot-deploy folder. We can then use that to add job-specific entity definitions, services, scripts, etc. Because ofbiz doesn't support runtime addition of components, it does require restarting, which is a little annoying. Webslinger itself does support adding new sites and mappings at runtime tho. Does that help answer your question? Or is it just a bunch of greek, or too much information? > >> >> Here is an example of what I mean by overlay: >> >> == >> doogie@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 >> doogie@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 >> doogie@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. >> > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |