Elation Framework Presentation

Transcript

1. The UI Takes raw data from all over the place (not pretty)... and turns it into a webpage (pretty to humans)... and an API (pretty to machines)
2. Core Concepts  A Site is made up of many Pages Pages  Pages Pages are laid out/wireframed using Panels Panels  Panels Panels fill in content by calling Components Components  Components Components are reusable controls which define application logic, UI elements, etc.
3. Panels  Defines HTML skeleton/wireframe using Config Config  CSS gives fine-grained control over layout  Components Components are responsible for content
4. Components  Components Components allow developer to split code into reusable, maintainable chunks  Components Components can consist of any combination of PHP, templates, CSS, and/or JavaScript  One Component Component can output any response type (HTML, JSON, XML, PNG, XSL, PDF, ZIP, etc)  Components Components can be built out of other Components Components, which in turn can be built out of other Components Components  Components Components can have multiple different Views Views and should adapt to the space they have available to them
5. Component Examples ui.sortablelist ui.tabview local.map user.friendpicker ui.button ui.treeview ui.combobox ui.progressbar ui.scrollable
6. Panels + Components Putting It Together
7. What Is ”The Framework”?  Actually two parts  Browser-side (Frontend)  HTML5/CSS3/JavaScript  Custom JavaScript framework to coordinate with server- side components  jQuery for rapid prototyping and initial build-out of new features  Server-side (Middleware)  PHP  Pulls data from any number of MySQL, Cassandra, QPM, REST, etc. sources with optional Memcache, APC, or disk caching  Generates HTML, JSON, XML, etc. responses  Old: Trimbo, New: Elation
8. Elation Overview
9. DataManager  Generalized data abstraction layer for any read/write datasource (MySQL, SQLite, file, Cassandra, CURL, REST APIs, etc)  Wrappers implement CRUD functions for data manipulation, and CREATE/DROP schema management  Generalized caching abstraction layer allows each data source to map to multiple cache types (memcache, APC, file, etc)  All queries are given a unique ID, which serves as a cache key if the source is associated with an active cache. Example ID: Example ID: db.userlists.$listname#$usertype,$userid db.userlists.$listname#$usertype,$userid  Key is used to route query to a specific source, with fall back on a default server for the given source type  #hash syntax enables sharding based on hash of specified attributes
10. DataManager Examples
11. ConfigManager  Manages software configuration for multiple site variations on a single server (cobrands, AB testing, etc)  Simple dot-separated heirarchical key structure with tree view admin tool
12. ComponentManager  Responsible for dispatching all Component Component requests  Three ways of calling Components Components:  URL /example/component?testarg=foo  PHP ComponentManager::fetch(”example.component”,array(”testarg”=>”foo”);  Template {component name=”example.component” testarg=”foo”}  Can automatically figure out content type to generate based on requested extension (HTML, JSON, XML, etc)
13. TemplateManager  Template engine transforms raw data into HTML  Extends Smarty (http://smarty.net) but could in theory be swapped out for any other template engine  Adds stack-based variable scoping on top of base Smarty functionality to simplify template/component nesting
14. DependencyManager  Keeps track of CSS, JavaScript, META tag, etc. Dependencies Dependencies during Page Page generation  Dependencies Dependencies are post-processed into the <head> of the HTML document  Examples:  {dependency type=”component” name=”thefind.corporate”}  DependencyManager::add(”javascript”, array(”url” => ”http://www.google.com/jsapi?key =...”));  {dependency type="meta" name="apple-mobile-web-app-capable" content="yes"}
15. OrmManager  Defines data model for each Component Component  Establishes relationships between data objects (one-to-one, many-to-one, many-to-many)  Models can be generated from an existing SQL schema, or vice versa  SQL queries are generated automatically  Thrift files can be generated from model descriptor files  Based on Outlet PHP ORM (http://outlet-orm.org)
16. Components – Ideal Case  Each component should have a singular, clearly defined purpose  Components should be general purpose with well- documented arguments to control variations in their behavior  The framework should come with a base set of general- purpose components for handling common interactive visual elements (forms, lists, panels, popups, sliders, etc)  More specific components should be build by combining these general-purpose components
17. Components – Reality  The components we have now have been developed haphazardly without planning. Arguments have been added as new features are dreamed up, and never documented  Inconsistent data and UI treatments make it difficult to reuse existing components because new projects don't take into account what we have already defined and how we can make use of it  Special-case logic is littered all throughout the code, both framework and component level. These special cases often cause undesired behavior when a component is used outside of its originally intended context