Dynamic Application Framework (NARM)

E.g. one of the most complex system units in Clinical Trial Planning system is "Visit Schedule" user interface which helps to interactively distribute Planned Visits and Planned Assessments (or their groups) across Clinical Trial Treatments. The "Visit Schedule" GUI is 2D representation of a multidimensional matrix where each cell can change its shape and event sensitivity (using runtime Action Command Injection) depend on preceding user intervention(s).

Nowadays market offers any number of so called dynamic Frameworks but non of these offer required context sensitivity. The most common drawback is the absence of layered architecture fundament. It seems there is some consensus that HTML markup language is presentable as application layer. Whereas HTML is not hierarchical enough with predominantly formatting stuff and suffers from lack of distinctiveness (e.g. there are any number of ways to construct menubars together with pull-down menus using various set of text formatting tags). Of course above mentioned Frameworks offer their own "tags" extensions which are more or less ugly aggregates of (Java and JavaScript libraries) and in the fact increase the development effort and cause high diversity of coding "handwritings" across web design companies. Such a diversity can turn into system maintenance nightmare.

The Network Application Rendering Model (NARM) represents a XML backboned meta-language which describes Web page hierarchical structure in distinct manner (see Figure 1, a bit simplified) where each application Web page is represented by NARM root node "ScreenDef".

Figure 1

NARM appl. structur definition is parsed after start of the Web application and from that date is part of in-memory Model View Controller (MVC) complex aggregate. Central entity of it is the State Machine (see Figure 2) which take influence in collaboration with currently involved ConditionDef(s) on the application shape.

Figure 2

Enter your comment or question