Consolidate repetitive ERP/MES pages into config-driven UI patterns

Context

At Walsin Lihwa, I primarily developed internal ERP and MES systems.

These systems had a distinct characteristic:

They contained many screens, workflows, and data fields, but when examined closely, numerous pages repeated similar operations.

For example:

• Query data
• Display lists
• Edit fields
• Create, update, and delete
• Validate data
• Control available actions according to state

If every new ERP or MES screen reimplemented its table, form, toolbar, and data flow, the features would work, but the system would quickly accumulate large amounts of code that looked slightly different while doing the same thing.

My Decision & Action

I began separating these recurring UI behaviors into two parts:

the operating model shared by every page, and the differences that truly belonged to an individual screen.

Shared data flows, CRUD behavior, field display, and editing modes were gradually organized into fixed patterns;

while the truly different parts, such as:

• Which fields exist
• How fields are displayed
• How fields are edited
• Where data comes from
• Which operations the screen allows

were described through structured configuration whenever possible instead of being reimplemented on every page.

I did not yet call it a complete config-driven framework, but the direction of letting code handle shared rules while configuration described differences had begun to take shape.

Outcome

Recurring page structures and data operations across ERP and MES could follow consistent UI patterns and data flows.

When adding features, the focus gradually shifted from:

“write another new CRUD page”

to:

“describe how this page differs from the existing pattern.”

This also reduced the chance that different modules would develop separate UI and data-processing approaches.

Reflection

This experience later became an important starting point for my config-driven thinking.

When many screens essentially followed the same rules, I began to realize:

What truly deserves to be implemented as code is the shared rule; repeatedly changing parts are better described as data or configuration.

This idea continued to expand throughout my later work.

At Gorilla, I encountered a mature config-driven no-code framework. Later, I even began using AST analysis to derive the schemas required by a framework directly from code.