Site builder example
For an overview of features, click through the slideshow

Fully multi-tenant, supports building stores, blogs or plain content sites
Products can have options, discounts, inventory
Accounts, multiple addresses, saved payment info
Back-office basic order tracking
Product description supports HTML
Skus with options and inventory
Product media assigned to specific options
Create new sites, edit menu entries, currencies supported
Create site pages with slideshows, html, product, category, and post views
Assign products/posts to a specific category or matching rules using expressions with code-hints
Manage skus
Create new option schemes
Basic statistics and user management
Manage media including flexible customization of different resolutions
❮ ❯

The site builder lets users build online stores, blogs or plain content web sites, complete with management UIs. It's a great example of how StrataCode can be used to create flexible, scalable SaaS platforms. The user profile management is used for analytics in www.stratacode.com but otherwise it has not yet been deployed. The code is readable, flexible and would make a great starting point for a scalable SaaS platform. It's also a fun way to explore a layered code base with enough complexity to see how it works. The best way to explore is with the IntelliJ plugin. Use the 'layers view' or line-markers to navigate up and down the layer stack, or find-usages and goto definition to jump around. The project view lets you find the files and understand the directory organization.

Project architecture
There are five main types of layers in the system. Each layer contains the code implementing a given feature that shares a common set of dependencies (e.g. database, server, file-system, HTML). In this design, the code is partitioned based on best practices for a scalable platform, to support a larger downstream ecosystem of use-cases with customizations. In a typical application project and especially when prototyping, it's better to use as few layers as possible, even as few files as possible. This structure has evolved to some degree to support various use cases: content without users, users without content, optional management UI, optional site-builder components.

Within each layer are a set of types, properties, and methods. Each of these becomes a customization hook point - a plugin or point to grab onto for downstream components to inherit rich, evolving behavior. Once established, layers can grow, inherit features from downstream, and sometimes split apart into multiple layers or be merged back again.

Types of layers
layer type description included in depends on
model domain model for feature client + server none
view model platform independent UI client + server none
server server parts server only file system + DB
html UI parts client + server html
html server html server specific code server only html, servlets
Project stats

The project is split into the major pieces: the domain model, the public website, and the back-office or management UI.

The domain model code is reused everywhere with no significant dependencies. The amount of code is kept small because domain model logic is not replicated.

Domain model(lines of code)
layer type content user product blog all description
model 310 360 1570 100 2340 domain model, e.g. ManagedMedia, UserProfile, Product, BlogPost
The view model layers are used in the client, server, and along with the server layers define the API, keeping HTML dependencies separate. The html layers run in the client and server to support isomorphic applications. Code that deals with http specific things like cookies, request headers is very small and kept in a separate set of layers.
Public website UI(lines of code)
layer type content user product blog all description
view model 780 0 370 130 1280 UI model - e.g. NavMenu, UserView, ProductView, BlogPostView
server 510 480 1340 250 2580 Server parts of model+view model - e.g. UserView.login(), ProductView.addToCart()
html 420 210 530 230 1390 Html view, mostly schtml templates e.g. PageLayout, LoginView, ProductView
html server 150 120 0 0 270 Html specific server code - e.g. MediaUploadPage, currentUserView (for request/cookie code)
total 2170 1170 3810 710 7860
Management UI(lines of code)
layer type content user product blog all description
view model 350 0 390 240 980 View model for management UI - e.g. SiteManager, PageManager, ProductManager
server 1050 90 1850 900 3890 Server part of view model - e.g. doSearch(), startCreatePage()
html 720 180 1360 240 2500 View for management UI - e.g. PageManagerView, SiteManagerView, ProductManagerView
total 2120 280 3600 1380 7370
Project stats
total lines 4290 1450 7410 2090 15230
num layers 9 9 7 7 32

The Site builder can be run in a number of different configurations:

  • with or without product, and blog
  • client/server or server only mode
  • run parts as dynamic for fast refresh
  • with or without the back-office UI

Getting started

Install postgresql on local machine, create user 'sctest' with password 'sctest' or configure the userName, password and other connection info in the layer definition file: user/dataSource/dataSource.sc. The product.demo uses the default scprod database. The ec.demo version uses an extended db scecom, and the blog.demo uses scblog. The first time you run a configuration, it will launch the schema wizard. Use the 'u' command to update the database schema, then 'q' to exit the wizard.

For an example of how to override properties of the data source without changing the original, see how the file: ec/demo/dataSource/dataSource.sc overrides the defaults in user/dataSource/dataSource.sc.

How to run each configuration of the application: # Site builder with all features scc -a ec.demoMgr.serverOnly scc -a ec.demoMgr.clientServer # Without management UI scc -a ec.demo.serverOnly scc -a ec.demo.clientServer # Site builder with product only scc -a product.demoMgr.serverOnly scc -a product.demoMgr.clientServer # Site builder with blog only scc -a blog.demoMgr.serverOnly scc -a blog.demoMgr.clientServer # To load the db for mapping postal code to city/state, geoIp database # for the scprod database # # To get geoIP download the GeoLite2 data created by MaxMind, available from # www.maxmind.com # # See user/addressDB/loader/loader.sc for additional instructions # scc -a user/addressDB/loader # Load the addressDB for the ec.demo configuration (the scecom database) scc -a ec/demo/loader # To run in dynamic mode for faster compile, refresh # see www.stratacode.com/status.html for known problems with this configuration scc -a -dyn product.demo.serverOnly

Video demos

In the SiteBuilder, changes made to products, blog posts, categories, skus, etc. in the management UI are reflected in real time on the live product pages. See this in action, and walk through the code that makes it happen.
See the storefront running in client/server mode, how layers organize into multiple processes, and how data-sync supports declarative code that runs in one process or split between client and server.
Layers in StrataCode support flexible ways to plug-in code and customize features. This demo walks through three different techniques used by the product feature.
A code walk-through of the UserProfile object in the SiteBuilder. See the database and data sync mapping annotations, an example data binding expression used as a queryable property, declaratively defined query, and look at the generated code for debugging.