A PHP centered system always renders its template into HTML, but Web 2.0 SPAs render the DOM directly in the browser. Such web applications usually consume a REST JSON API .
-
short term:
render variables that would be rendered into the html as a nested object/array JSON datastructure, so simple getJSON requests (requesting "application/json" datatype) can grab a state of the game too - this will achieve data access freedom (with session authorization, or better token bearer based authentication).
- IMHO this would synergize well with the open(-source)ess of the project.
- data serialization can be easily accomplished, e.g.
U_Unit { .. public json_serialize: { json_encode($this) .. }
-
longterm:
develop the interface design defining and refining it, covering all entities in further iterations
-
benefits:
API spec is shared between client and server and is a perfect layer to write tests against. the spec wont depend on any implementation or language details - concentrating on the domain model entities and possible actions and their validation upon them.
A PHP centered system always renders its template into HTML, but Web 2.0 SPAs render the DOM directly in the browser. Such web applications usually consume a REST JSON API .
short term:
render variables that would be rendered into the html as a nested object/array JSON datastructure, so simple getJSON requests (requesting "application/json" datatype) can grab a state of the game too - this will achieve data access freedom (with session authorization, or better token bearer based authentication).
U_Unit { .. public json_serialize: { json_encode($this) .. }longterm:
develop the interface design defining and refining it, covering all entities in further iterations
benefits:
API spec is shared between client and server and is a perfect layer to write tests against. the spec wont depend on any implementation or language details - concentrating on the domain model entities and possible actions and their validation upon them.