[logseq-plugin-git:commit] 2025-06-04T10:34:00.401Z

2025-06-04 12:34:00 +02:00
parent 33d3628766
commit c0facf72f4
1 changed files with 0 additions and 1 deletions
@@ -27,7 +27,6 @@ progress:: {{renderer : todomaster}}
 				-
 		- query-table:: true
 	- ## [[PAPERS/NOTES]]
-	  collapsed:: true
 		- Revised section
 			- The evolution of data-intensive web applications has predominantly relied on model-driven approaches that emphasize the separation of functional descriptions from implementation platforms. Over the last decades, many modeling languages have been proposed mainly based on three modeling constructs, i.e., data, page, and navigation. In particular, *data modeling* was crucial. Early frameworks used relatively homogeneous data sources, which were meticulously structured to ensure consistency and ease of maintenance. The models described the data schema—defining entities, relationships, and attributes—that formed the backbone of the applications. The concept of *pages* in early web applications was straightforward yet foundational. Each page represented a cohesive unit of content and functionality structured around the underlying data model. Pages were designed using templates that dictated layout and style, often leading to static presentations that required significant effort to update or personalize. *Navigation* models were integral, defining the paths users would take through an application. These models outlined how pages were interconnected, facilitating user movement across sections and functions of the website. Navigation was typically rigid, reflecting the static nature of early web architectures, with limited dynamic capabilities or user-driven paths.
 			- As shown in Table \ref{tab:}, initial modeling platforms were often standalone systems that provided tools for defining and manipulating these constructs without detailed programming knowledge. However, these systems commonly offered a low level of user experience and were not designed to support rapid, iterative changes. The platforms were monolithic, coupling data, presentation, and navigation in ways that made updates cumbersome. The development processes were traditional and non-agile, lacking the flexibility to adapt quickly to new requirements or user feedback. Integration with emerging DevOps practices was limited, further slowing the evolution of applications as they could not effectively leverage continuous integration or automated deployment techniques.