design js

Page Loads Basic CSS Initialize JS Queue Basic HTML Initializer JS Query into page config Page config sets data+source Page config queries into templates Template comtext injected into execution context Execution follows template context execution path to end

Execution Path Example Root Page -> Load requsted template-set Admin Page -> Get Current Tab Info from Context, regiser hotkey handler Load: User Perspective -> Get user data from Context Load: User List Template * Render individual users -> Populate user callbacks

Inline Partials!

Root Page (Header/Body/Footer) Top Bar (Logo/Search/Login)

Manifests

Read app/templates/raw/*

Templates

Need a single view file per controller. All template selection happens in JS.

  / First tag must compile to javascript.
  coffee:
    # Repeated calls to setup functions will be executed in order declared
    loaded: (render_context) ->
    # Executed when the template is first loaded into the render engine
      #   May be used to inject new dependences and subtask into the context
      #   Useful for pre-loading tempplates which may be necessary later
      render_context.inst_handlers # The handlers defined below
    inst: (render_inst_context) ->
    # Executed when the template is instantiated, must yield to render
      render_inst_context.container # The DOM element to contain the actual template
      render_inst_context.locals # The variables to be passed into the render stage
      render_inst_context.yield() # Calls into the render stage
    cleanup: (render_inst_context) ->
    # Executed when the template is removed from the document.
  / All subsequent HTML will be converted into an EJS template
  .example
    .slim
  / Inline Partials are extracted from the slim document, and served with the template
  partial
    coffee:
      ...

Template Server

Contexts

Context provide generaized control for global variables which provide a backing for the current thread of execution.

• Initializing

  sereth.context.bind(type, object)
  sereth.context.bind(type, () ->)


  context.register_type(type_name, () -> ret_1)
  context.global_type(global_name, () -> ret_2)

  context.link_type(context_node)

  context.get_data(data, value_1)
  context.global_data(g_data, value_2)

  context.enter(name, () -> populate)
  # If name does not exist, then run the populate
  # Enter name and run the entry handlers

  context.leave()
  # Remove global data defined in the current context, and repopulate parent entry


  # Then
  # Note, globals can be retrieved with get_* too
  context.get_type(type_name) #=> ret_1
  global_type #=> ret_2

  context.get_data(data) #=> value_1
  g_data #=> value_2

• Using

Contextual data exists

  # in render
  inst.get('name')

  $(".name_#{item.id}").value = item.name for item in list

Page Header Logo (static) Search (signaled inst) link go (video dynamic list) Options Nav Options (static list) Subscriptions (static list) Content = Video List (video dynamic list) Filters (signaled inst bound to lists) Videos Pages Footer (static)

Page - Root Context

Page Header

Tunnel Define Spec (What JSON looks like, object name, spec name, server url) Instantiate first request Get data from server

Save data to server

Render Bind data to sets of templates for rendering instance/list/form perspectives

Allow server pushes from changes made to defined forms

Usage: Take a bunch of data Originated from tunnel bind data to perspectives (auto?)

render data into containers

render data into perspectives perspective starts a new window level container (context) perspective management happens with entry/exit callbacks

perspective context pre-configured by parent

rendered forms are bound to data objects. Form updates are saved to objects, which are then pushed to the server as necessary. call back before populate, then before and after commit before populate for custom data validation and such

Templates - Templates contain slim style code, and context javascript. Any script tags in the resulting object are extracted and parsed in the context of the given location. Context has access to a container element which contains the generated html.

Template should allow for inline definition of sub-templates for quick 

Context - Contexts provide a shared space for accessing functions and variables.

Contexts are managed by callbacks which populate the actual contex entries

From your contextual position you can see multiple contexts. If you've created a context
but did not define a link type for it, the future link searches will query super-cts links

Context need follow linkage

Admin Environment
  Initiate root Worker Context W1
  Renders admin header
    Render provided HTML
    Does system wide init operations
  Load Tree Node page
    Create a worker context (W1 ->) W2
    Create a data context D1
      Bind tree node spec to created data context
      Link data to worker contexts
    Create a render context R1
      Bind render inst to create render context
      Link render to worker context
  Edit a Tree Node
    Create a content context (C2 ->) C3
    Create a render context (R1 ->) R2
    Query content for data link - returns C3 -> C2 -> D1
    Update some data to create (D1 ->) D1*
    Save D1*
    Leave content context C3
      Should return to (C2 D1 R1)
      Should notify D1 to reload due to D1*

Query contexts

Default access to worker context window.context

Access to object's context this.context

context.name -- Get the [name] type bound to the worker context or {}.context

generate_context(object, type) OR (object, ctx_parent) local_context.name --

Object.proto.test = function () {console.log('1')}; a = function () { this.test = function () {console.log('2')}; }

a.prototype.woo = function () {test()};

aa = new a(); aa.woo();