The client stated that we have a REST API available to us. In fact, they have other Ext JS applications to be built on top of this API and so we're lucky. The data is returned as JSON that can be easily consumed by Ext.data. The customer provided documentation on how the API operates:

API Endpoint: http://localhost:3000

GET /pages
Accepts: n/a
Returns: [{ id: 1, text: 'label', children: [] }, { id: 2, text: '', children: [] }]

PUT /page
Accepts: {"published":true,"stub":"our-work","body":"Our Work.","id":"5e30c0a3-729a-4719-a17f-7e2286576bda"}
Returns: {"success":true}

POST /page
Accepts: {"label":"New Page","text":"New Page","leaf":true,"id":"Unsaved-1","parentId":"5e30c0a3-729a-4719-a17f-7e2286576bda","published":true,"stub":"new-page","body":"A New Page."}
Returns: [{"clientId":"Unsaved-1","id":"2ae28c61-cc6e-4a98-83ee-f527f4b19f1e","text":"New Page","body":"A New Page.","published":true,"stub":"new-page","leaf":true}]

DELETE /page
Accepts: {"id":2}
Returns: {"success":true}

At this point, your developers will be dancing a little jig because not only do you have documentation, but also the API is very straightforward supports only a few operations.

Our part of the data implementation becomes easy now. We know that we want to implement a treeview. The data coming back from /pages is already formatted correctly for this with an array of children and both ID and text properties. We only need one model to represent a page, so it'll look something like this in pseudo-UML:

ArchitectureCms.model.Page: extends Ext.data.TreeModel
- id
- stub
- published
- body
- [] children

Then, we'll have a super simple store to collect these models together:

ArchitectureCms.store.Pages: extends Ext.data.TreeStore

There's no custom logic hanging off the store so that's literally our full definition, although we know that our implementation will be configured to use our ArchitectureCms.model.Page.

The data layer is the one through which everything will be built on. Although our design for this layer is super simple for this application, it's worth writing it in case we see any glaring issues. We can now look at how these data classes will interact with the user interface and glue classes in the rest of our application.