| 1 | # Arthus
|
| 2 | --------
|
| 3 |
|
| 4 | A solid framework for building webapps.
|
| 5 |
|
| 6 | ## Goals
|
| 7 |
|
| 8 | * All pieces should be separated and decoupled. Everything should be easily
|
| 9 | testable. That means no globals or anything.
|
| 10 | * A common pattern for controllers and helpers.
|
| 11 | * Framework should be separated from the actual app.
|
| 12 | * A great view layer.
|
| 13 | * Utilize streams where possible.
|
| 14 | * Fast, of course.
|
| 15 | * Include client-side framework.
|
| 16 | * Great support for rich JavaScript client applications.
|
| 17 | * Easy to profile and benchmark.
|
| 18 | * Centralized logging.
|
| 19 | * Follow Node patterns.
|
| 20 | * Great for developement.
|
| 21 |
|
| 22 | ## Implementation
|
| 23 |
|
| 24 | How to reach each of the goals.
|
| 25 |
|
| 26 | ### Decoupled and separated parts
|
| 27 |
|
| 28 | Different parts of the application will always require some kind of
|
| 29 | configuration. Instead of putting the configuration in a global location,
|
| 30 | each part gets the configuration passed on instantiation.
|
| 31 |
|
| 32 | This can be done automatically by mapping the configuration section to the
|
| 33 | name of the object that needs variables.
|
| 34 |
|
| 35 | ### Common pattern for object
|
| 36 |
|
| 37 | By defining strict rules for how object constructors may look this can be
|
| 38 | generalized.
|
| 39 |
|
| 40 | ### Framework separation
|
| 41 |
|
| 42 | By writing the framework itself as a separate project we can further force
|
| 43 | ourselves to separate app logic from framework logic.
|
| 44 |
|
| 45 | ### Great view layer
|
| 46 |
|
| 47 | Each controller should return a view object. The view object is an object
|
| 48 | that defines how a page should be rendered. The framework will then inspect
|
| 49 | this object and render it and pass it to the browser.
|
| 50 |
|
| 51 | During AJAX requests this view object can be serialized to JSON and sent to
|
| 52 | the browser for rendering on the client.
|
| 53 |
|
| 54 | ### Utilize streams
|
| 55 |
|
| 56 | The view layer could possibly be abstracted to work with streams in some way.
|
| 57 |
|
| 58 | ### Client side framework
|
| 59 |
|
| 60 | On the client side there should be a router layer that correctly invokes the
|
| 61 | controller for the current page.
|
| 62 |
|
| 63 | The view objects from the server should be made to work on the client.
|
| 64 |
|
| 65 | View objects defines a target for how it should be rendered. For incremental
|
| 66 | requests (like endless scrolling) they can set a selector and wether the
|
| 67 | result should be prepended or appended to the target.
|
| 68 |
|
| 69 | The client side should support single page applications where supported by the
|
| 70 | browser. Pages should be stored in the DOM to make jumping back and forth a
|
| 71 | breeze.
|
| 72 |
|
| 73 | ### Easy to profile
|
| 74 |
|
| 75 | I believe this is achieved by writing clear, separated logic. Hooks and events
|
| 76 | will have to be provided for this kind of functionality to sit outside the app.
|
| 77 |
|
| 78 | ### Centralized logging
|
| 79 |
|
| 80 | The application should provide a simple way of doing logging. Runtime
|
| 81 | configurations can then be made to decide where the log messages are sent.
|
| 82 |
|
| 83 | ### Follow Node patterns
|
| 84 |
|
| 85 | Callbacks should all do error first. All that good jazz.
|
| 86 |
|
| 87 | ### Great for dev
|
| 88 |
|
| 89 | Keep convention over configuration for stuff like folder structure etc.
|
| 90 | Provide scaffolding methods for creating models, helpers, controllers etc.
|
| 91 |
|