Purpose

Purpose

I'm not, traditionally, a JavaScript person. When I got into webOS development, I started with Mojo and moved to Enyo. I gravitated to this framework because of the documentation, community supported by Palm (later HP) and the structural layout makes sense to me.

This project is a boilerplate that can be leveraged to rapidly prototype an application or website. The challenge is finding a balance between easy to understand and useful. Hello World apps are usually trivial, and full blown projects often too specialized to be leveraged for starting a clean project.

There are many excellent Enyo projects with open code base, etc. But I wanted to provide something that solves a lot of the web site housework. To that end, this project, along with the REST back end server, provides the following capabilities:

1. Basic web site or packagable application 1.1 Templated presentation structure with shared headers & footers
2. User Sign Up
3. Email Integratiuon
4. Password Recovery
5. Email address verification
6. Contact Page
7. Intra Site Messaging
8. System Notifications
9. User Terms & Conditions
10. User/Site Administration
    10.1 IP Range Checking for Administrator accounts
    10.2 Modify User Accounts
    10.3 Delete User Accounts
    10.4 Send System Notifications
    10.5 Create Terms & Conditions
11. Manage session timeouts
    11.1 Single page web apps need to manage or link to the backend server
    11.2 Provide an alert or feedback when the session is about to timeout
    11.3 Auto logout when the session expires

Missing

Lots. That's kind of the point, not to create a highly specialized web site that someone has to rip apart. So the website does SOMETHING, but not ANYTHING.

The presentation is default Enyo. I would like to figure out an easy way to skin the site. Theming is supported, just haven't focused on this yet: LESS for customizable styling.

Challenges

Lots of challenges with this project. For one I probably deviate from many Enyo projects because I'm trying to build around web site requirements, as opposed to application requirements. So I had to solve a number of issues, and doing so in an inheritable way:

1. Restricting page views by Unauthorized users (public vs. authenticated)
2. Session timeout 2.1 Common challenge with single page web apps is managing the user's session in the client, when the backend server is the system of record
3. Templating: Probably not true templating, but trying to build a logical structure to separate page bodies from all the navigation
4. Dynamic Enyo 4.1 Enyo lends itself well to statically defined components. While dynamic instantiation is supported it can create issues

Feature Creep

I did add some features above and beyond my original intent, but thought they would be a valuable addition to anyone seriously using this to prototype a web site:

1. Developer button 1.1 This can be turned on or off in the build (or from the JavaScript console on the fly) 1.2 Allows the user to change the backend server address and ports 1.3 Useful because for testing against different IP addresses on the fly 1.4 For example running everything on a LAN but wanting to test form different machines/devices
2. Beta Site Feature 2.1 Again, this can be turned on or off 2.2 If On, or if the server reports Beta mode is On, the Admin sees a Beta Site button 2.3 Admin can turn Beta On or Off 2.4 Admin can generate & email Beta invite codes 2.5 When Beta is active, users need a beta code to sign up

Future Creep

There are still some things I think can be added without overly complicating the project:

1. Skins
2. Better mobile support 2.1 Right now the app simply scales to fit in the screen, so buttons are timy on phones 2.2 If I let Enyo scale 1:1, then there are issues scrolling around on a phone, then it's difficult to see everything
3. Paid subscribers 3.1 The database supports User/Subscriber/Admin roles 3.2 Shouldn't be too hard to differentiate between Users and Subscribers as unpaid and paid accounts
4. Payment System Integration
5. OAuth allowing users to login with Google, Facebook, Twitter, etc.
6. Message Boards (probably too much, doubt I'll go there)
7. Reorganize the navigaton routes so they're not all defined in Routes.js

Presentations on Enyo

<a href=http://www.slideshare.net/RoySutton/html5-apps-write-once-deploy-anywhere-with-enyo" target="_blank">Write Once, Deploy Anywhere

Quick Start

Quick Start

Screen Shots

Screen Shots

Tutorial Walk Through

Add a Contact Page for Authorized users

Project Architecture

Application Architecture

Project Directory Structure

Directories and Package Layout

Architectural Decisions

Why is the project structured this way?

Implementation Decisions

Why are some things implemented this way?

Known Issues

Package Layout & Code Inheritance

Home

Home