IT:AD:Design:Blueprints:View Layout Service

Summary

Almost all Enterprise applications have static layouts that cannot be updated later without a redeployment.

Why? Mainly, because it's perceived as much more difficult to produce a UI rendering mechanism that can later be reorganized, dynamically, at will.

All current 2D applications – whether WIMP/ based, or CUTE/ based, are hierarchical in nature.

I've already covered this here:

To manage that, you'll need schema definition system similar to the following.

ViewId: intEnabled: boolOrder:intIsContainer: boolIsContainerBoundary:boolChildrenCanBeMoved: boolICollection<View> Views: ICollection<View>IconIdentifier: stringTitle: stringHeader: stringFooter: stringRenderers: ICollection<ViewRenderingFrameworkControl>ViewControlId: intViewFK: intId: intEnabled: boolTag: stringViewRenderingFrameworkControlId: intViewFK: intRenderingFramework: ViewRenderingFrameworkViewControlFK: intViewRenderingFrameworkId: intName: stringReally just a db mapping of an Enum. Contain 1 (2?) entries (eg: 'ASP.MVC', 'ASP.Classic')Tag will be something the rendering engine can use. (eg: an *.ascx path, a *.cshtml path)1*1+*1*1

Rendering Systems

Some of you may be wondering about the validity of the indirection provided by the ViewRenderingFramework collection.
In most cases I'll agree that the lifespan of the rendering framework will generally outlive the usefulness of the application.

But I'm the kind of guy that likes being prepared. For one small little friction, I'll be able to move to the next system, whereas everybody else has to practically rip out their whole app and start again.

When did Noah build the ark? *Before* the flood. *Before* the flood.
  • /home/skysigal/public_html/data/pages/it/ad/design/blueprints/view_layout_service.txt
  • Last modified: 2023/11/04 03:40
  • by 127.0.0.1