Architecture
This application is a Single Page web application, which uses a REST API for communicating with the database. The Enyo code is loaded into the browser (or deployed application container) which relies on a remote server for session management and CRUD database functions.
This project based off of a fork of the Enyo MVC Bootplate project.
The Enyo Sampler lets you see design elements and view the code used to generate the page.
Below is a quick overview of the important constructs in the project. More details can be found by drilling into the pages describing the code.
Someone correct me if I'm wrong.... A 'Kind' is how Enyo defines a JavaScript Class with inheritance. At some point in the tree, everything inherits from 'enyo.Object'. 'enyo.Object' has no 'Kind'. Of course other JavaScript constructs can be used, there's no limitation to use only Enyo Kinds.
Enyo instantiates a Kind which is the application starting point:
enyo.kind({ name: "Bootplate.MvcApp" , kind: "enyo.Application" ... });
####Controller structure
Routes : Handles navigation, such as between pages and controllers. Originally tried to break up into multiple Routers based on functionality, but only the last one would be recognized. So had to combine everything into one big route. May be able to have one route that imports multiple route files based on their functionality?
**PublicController** : handles functionality when a user is not logged into the site
**AuthController**: Handles functionality after authentication (priviledged functionality)
####Views Structure The goal is to organize views and events. Originally a Controller and View were going to be a pair and used for functionality (i.e. user preference pages). However, the view is really a container for the content, still trying to figure out how/when/where it makes sense to compartmentalize content and functionality.
** ParentView** : Controls setting up a page, including the Headers, Footers, Navigation and Content. The views each have a 'bodyContainer' component used to contain and control viewing of the page body content.
**PublicView** : Maps to the PublicController, has a PublicHeader, PublicContent and PublicFooter. Initial content is the LoginContent.
**AuthView** : Maps to the AuthController, has an AuthHeader, AuthContent and AuthFooter. Initial content is the HomeContent.
**Headers & Footers** : There is a Publicly viewable Headre and Footer and a set for users who are logged in.
**Navigation Toolbars** :Again a public set and authorized user set. Additionally, an Administrator sees an Admin toolbar at the bottom.
**Parent Page** Not to be confused with ParentView (maybe should be renamed to something else, but "Content" was more confusing). All Pages extend this Kind, this is what gets inserted into the View's Body Container.
**Authorized vs. Public Pages** : The authFlag is set in each Page. This is used in various places to determine if the user has access to the page. This should be expanded beyond boolean. I hate to make a mapping, but it is conceivable that the routing should be controlled based on whether the user is:
- Guest visiting the site
- User who's logged in
- Paid subscriber (premium pages)
- Some pages should allow user no matter what state they'r ein
- For example currently a separate contact page is required for a visitor and someone who'd logged in (No contact page for auth users at this time, see the tutorial which walks through adding a contact page)
####Routing The Routes controller intercepts links and uses the appropriate handler. Navigation can be handled via linking: <a href="#/logout">Logout</a> or programitically: mvcApp.$.publicRoutes.trigger({location:'/login'})
An incomplete class diagram.
Gives a sense of how everything is put together.
Add a Contact Page for Authorized users
Directories and Package Layout
Why are some things implemented this way?