Difference between revisions of "Architecture"

From CMC for PHP
Jump to: navigation, search
(Model View Presenter?)
 
Line 1: Line 1:
 
===Model View Presenter?===
 
===Model View Presenter?===
  
The closest pattern of this framework is probably the Model-View-Presenter one. This as to be confirmed by other people.
+
The closest pattern of this framework is probably the Model-View-Presenter one. This has to be confirmed by other people.
  
 
The general architecture widget oriented, organized in logical frames.
 
The general architecture widget oriented, organized in logical frames.

Latest revision as of 01:58, 18 May 2021

Model View Presenter?

The closest pattern of this framework is probably the Model-View-Presenter one. This has to be confirmed by other people.

The general architecture widget oriented, organized in logical frames.

The main concepts in the framework are:

  • a view is a combination of materials, and is a result of an url request
  • a material is a single piece of visual data, for now a piece of html code. In general this could be other kind of visual document language.
  • a frame is the implementation of a portion of a view. You can (and usually have) multiple frames needed to render and manage an single view. A specific part of the view can be affected by several frames.
  • a widget is an helper component to render the view from the frame definition, and manage value exchanges. The widget implements an initial render in the view, and additional updates using POST messages (currently Json with jQuery). The widget definition is making the relationship with the material (using HTML id mostly), and optionally the data model.

In other words: An application defines frames which defines widgets for values and control. This is the logical, or 'controller' part. The application defines view materials using HTML, standard HTML. HTML views can be defined with parts in order to split logics.

The main engine is first loading the view assembling materials, and then is seeking for the frames to handle that view. Having no frame for it is not erroneous: in this case the HTML view is rendered 'as is'.

Decoupling

View and presenter are not totally decoupled: the relationship between components (labels, input, tables, ...) is defined by identifiers in the view. The classical javascript way.

Additionally views are linked together using custom attributes, but remain standard HTML.

Main goal is to enable 'decoupled' work for designer and presenter programmer. The presenter programmer is responsible for decoupling with back-end programs.