DEV Community: sugaiketadao

Always Pair VLOOKUP with ISNA (or IFERROR)

sugaiketadao — Sat, 11 Apr 2026 08:23:49 +0000

The Problem

VLOOKUP returns a #N/A error when the lookup value isn't found.

=VLOOKUP(A2, ProductMaster!A:B, 2, FALSE)

If the value in A2 doesn't exist in the product master, the cell shows #N/A.

That's annoying on its own — but the real problem is that any formula referencing that cell also breaks.

=SUM(B2:B10)  -- if any cell in range is #N/A, the whole SUM returns #N/A

Fix with ISNA

ISNA returns TRUE if the value is #N/A, FALSE otherwise. Combine it with IF:

=IF(ISNA(VLOOKUP(A2, ProductMaster!A:B, 2, FALSE)), "", VLOOKUP(A2, ProductMaster!A:B, 2, FALSE))

When no match is found, the cell returns an empty string instead of #N/A. The cascading error problem goes away.

Shorter: Use IFERROR

Excel 2007+ has IFERROR, which is the modern standard:

=IFERROR(VLOOKUP(A2, ProductMaster!A:B, 2, FALSE), "")

Much cleaner. One caveat: IFERROR catches all errors (#REF!, #VALUE!, etc.), not just #N/A. If you need to distinguish between error types, stick with ISNA.

Comparison

Approach	Length	Error scope
`ISNA` + `IF`	Verbose	`#N/A` only
`IFERROR`	Concise	All errors

Bonus: Use ISNA for Conditional Display

ISNA is also useful when you want to show a value based on whether a match exists:

=IF(ISNA(VLOOKUP(A2, ProductMaster!A:B, 2, FALSE)), "Not found", "Found")

Takeaway

Whenever you write a VLOOKUP, wrap it in IFERROR right away. It's a simple habit that keeps your spreadsheets clean and prevents confusing error cascades.

About SIcore Framework

I'm building an open-source Java framework designed to make enterprise web app development straightforward — even for junior developers. HTML, CSS, JavaScript, and Java are all structured around consistent, minimal conventions.

Website: https://onepg.com
GitHub: https://github.com/sugaiketadao/sicore
How to verify sample screens (VS Code): https://github.com/sugaiketadao/sicore#%EF%B8%8F-how-to-verify-sample-screens---vs-code
Getting started with AI development: https://github.com/sugaiketadao/sicore#-getting-started-with-ai-development

Thanks for reading!
If you found this useful, a ❤️ would mean a lot.

CSS Blocks and Inlines — What I Wish I'd Known on Day One

sugaiketadao — Fri, 03 Apr 2026 11:19:07 +0000

Introduction

"I set a width but nothing changed." "The top and bottom margin isn't doing anything." "I just want these elements side by side but it's not working."

If you've spent time staring at CSS that refuses to cooperate, there's a good chance the root cause was the difference between block and inline elements — and that knowing this one concept would have resolved most of those issues instantly.

Here's why it matters:

You can immediately understand why a CSS rule isn't taking effect
You know exactly where to look to fix it
You know what to check in the browser DevTools

Not knowing this means hours of trial and error. Past-me knows this all too well.

Block vs. Inline — The Short Version

Every HTML element has a default display behavior: it's either block or inline.

	Block elements	Inline elements
Layout direction	Stack vertically	Flow horizontally
Width	Stretches to fill the parent	Shrinks to fit content
`width` / `height`	Works	Does not work
`margin` (top/bottom)	Works	Does not work
`padding` (top/bottom)	Works	Visually expands, but doesn't push adjacent elements
`line-height`	Works	Works
Common tags	`<div>` `<p>` `<h1>`–`<h6>` `<ul>` `<li>` `<table>`	`<span>` `<a>` `<strong>` `<em>`

Block Elements

<div>div (block)</div>
<div>div (block)</div>

┌────────────────────────────────────┐
│ div (block)                        │
└────────────────────────────────────┘
┌────────────────────────────────────┐
│ div (block)                        │
└────────────────────────────────────┘

<div> is a block element by default. Without any CSS, it stretches to fill the full width of its parent and pushes the next element below it.

width, height, margin, and padding all work exactly as you'd expect.

Inline Elements

<span>span (inline)</span>
<span>span (inline)</span>

┌─────────────────────┐┌─────────────────────┐
│ span (inline)        ││ span (inline)        │
└─────────────────────┘└─────────────────────┘

<span> is an inline element by default. It flows horizontally alongside other content and only takes up as much width as its content needs.

CSS That Doesn't Work on Inline Elements

span {
  width: 200px;        /* No effect */
  height: 100px;       /* No effect */
  margin-top: 20px;    /* No effect */
  margin-bottom: 20px; /* No effect */
  padding-top: 20px;   /* Visually expands, but doesn't push neighbors away */
  line-height: 2;      /* Works — line-height applies to inline elements */
}

This is the root cause of most "why isn't this CSS working?!" moments.

Switching Display with the `display` Property

The display mode can be changed with the CSS display property. This is the key to resolving most of the issues above.

Make an inline element respond to size and vertical margin → `display: block`

a {
  display: block;
  width: 200px;
  margin-top: 20px; /* Now works */
}

Commonly used to expand the clickable area of a link beyond its text.

Make block elements flow side by side while keeping size control → `display: inline-block`

div {
  display: inline-block;
  width: 100px;
  height: 100px;
}

inline-block gives you the best of both worlds: elements flow horizontally (like inline), but width and height are respected (like block).

┌──────────┐┌──────────┐
│   div    ││   div    │
│ 100×100  ││ 100×100  │
└──────────┘└──────────┘

Common Traps

Trap 1: Setting `width` on a `<span>` has no effect

/* ❌ span is inline — width is ignored */
span {
  width: 200px;
}

/* ✅ Change the display mode */
span {
  display: inline-block; /* or block */
  width: 200px;
}

Trap 2: `<a>` tags have a tiny click area

Navigation links where only the text itself is clickable:

/* ❌ Padding doesn't push neighboring elements */
a {
  padding: 10px 20px;
}

/* ✅ Make the padding work properly */
a {
  display: block; /* or inline-block */
  padding: 10px 20px;
}

Trap 3: Trying to place `<div>` elements side by side

/* ❌ div is block — elements stack vertically */
div {
  width: 100px;
}

/* ✅ Option 1: inline-block */
div {
  display: inline-block;
  width: 100px;
}

/* ✅ Option 2: flexbox on the parent (the modern approach) */
.parent {
  display: flex;
}

Flexbox handles horizontal layout, centering, and even spacing distribution. If you're learning CSS today, prioritize flexbox over inline-block — it covers almost everything you'd want for modern layouts.

Check It in DevTools

You can confirm any element's display value instantly in the browser's developer tools (F12):

Right-click the element → "Inspect"
Open the Computed tab on the right
Search for or find display

Once you see "display: inline — that's why width isn't working," you know exactly what to fix.

Quick Reference

display: block        → Stacks vertically. width/height/margin all work.
display: inline       → Flows horizontally. width/height/vertical margin don't work.
display: inline-block → Flows horizontally AND width/height work.
display: flex         → Flexible layout for children. The modern standard.

Whenever a CSS rule doesn't seem to apply to a new element, make it a habit to ask: "What is this element's default display value?" That single question will dramatically speed up your debugging.

Wrapping Up

Block vs. inline feels like a minor detail at first. But knowing the distinction changes how fast and how confidently you work with CSS.

I think back to the time I spent wondering "why isn't this working?" — and I wish I'd had this explanation then.

Next time a width doesn't seem to apply or elements refuse to go side by side, come back to the table at the top of this article. The answer is almost certainly there.

SIcore Framework Links

I've published a Java framework designed for SI projects, built so that even junior programmers can develop business applications with ease. The HTML, CSS, JavaScript, and Java structure is cleanly organized, and you can learn by running the sample code.

Website: https://onepg.com
GitHub: https://github.com/sugaiketadao/sicore
How to verify sample screens (VS Code): https://github.com/sugaiketadao/sicore#%EF%B8%8F-how-to-verify-sample-screens---vs-code
Getting started with AI development: https://github.com/sugaiketadao/sicore#-getting-started-with-ai-development

Check out the other articles in this series!

Thank you for reading!
I'd appreciate it if you could give it a ❤️!

Why Go Vanilla? — Why I Built a Java Framework (third attempt in 10 years) #11

sugaiketadao — Thu, 02 Apr 2026 01:07:36 +0000

Introduction

In articles #02 through #10, I introduced the design and features of the SIcore framework. In this final installment, I want to step back and explain the philosophy behind every design decision I've described — why I built it with vanilla (plain Java, JavaScript, and HTML).

SIcore uses no annotations in Java, no JavaScript framework, no template engine for HTML, and no Bootstrap or Tailwind for CSS — just a hand-written 400-line stylesheet.

Going vanilla is a practical choice that pays off in two concrete ways: compatibility with AI code generation and a design that beginners and junior developers can actually learn from.

What "Vanilla" Means Here

Here's a summary of what SIcore deliberately does not use:

Layer	What's omitted	SIcore's alternative
Java	Spring Boot, annotations, DI	Direct URL-to-class mapping (#02), reflection
Java (SQL)	MyBatis, JPA, XML definitions	SQL written directly in Java — SqlBuilder / SqlConst (#10)
Java (data)	Entity / DTO / Bean	Map-based design — Io class (#07)
JavaScript	React, Vue, Angular	Vanilla JS + framework utilities
HTML	JSP, Thymeleaf, template engines	Static HTML + JSON communication (#03, #04)
CSS	Bootstrap, Tailwind	Custom 400-line stylesheet (#08)
Server	Tomcat, Jetty	JDK standard HttpServer

In short: enterprise business apps work with nothing beyond the JDK and browser standards.

This isn't a philosophical stance. It's the result of chasing practical outcomes.

Benefit: Plays Well with AI Code Generation

As I mentioned in #01, a design that's beginner-friendly turns out to also be AI-friendly. Here's why.

Unified patterns

Every screen and every process in SIcore follows the same pattern.

JavaScript side:

const req = PageUtil.getValues();
const res = await HttpUtil.callJsonService('/services/module/ClassName', req);
PageUtil.setValues(res);

Java side:

public void doExecute(Io io) throws Exception {
    IoItems row = SqlUtil.selectOne(getDbConn(), LOAD_SQL.bind(io));
    io.putAll(row);
}

Three files — HTML, JS, Java — and one screen works. No routing config, no bean definitions.

AI performs better when patterns are consistent. SIcore documents its coding patterns (21-event-coding-pattern.md), and loading that document into the AI's context produces highly accurate business code.

Lower token consumption

AI tools like GitHub Copilot have limits on how much code (tokens) they can hold in context.

Spring Boot is well-represented in AI training data, but version drift is significant — models generate outdated code or misread project-specific configurations. A custom framework doesn't exist in training data at all, so it must be passed as context every time. But that's only a problem if the context is large.

SIcore's core is small (Java ~5,000 lines, JavaScript ~2,000 lines), and the API reference documentation is compressed specifically for AI use. The entire framework can fit in a reasonable context window.

No magic

Annotations, DI, AOP — these are mechanisms where things happen "automatically" behind the scenes. AI knows these concepts in the abstract, but without the actual code in context, it can only guess at what your project-specific setup does.

In SIcore, the full execution flow is traceable in code. How a URL becomes a class name (#02), how HTML and JSON are transformed (#04) — all of it is readable. When generating code, AI never needs to infer invisible behavior.

The same applies to SQL. Because SIcore writes SQL directly in Java (#10), AI can see exactly what query runs — no XML-to-code linkage to trace.

Works for beginners too

What's easy for AI is easy for humans who are just starting out.

Unified patterns mean you always know what to write next. No magic means you can follow why something works. SQL in code means you can see what data flows where. These are ideal conditions for learning enterprise app development.

"Run it, then read it" is a valid learning strategy here. Someone with basic Java knowledge can start writing business code within days. (In theory. 🤞)

Welcoming AI as a New Kind of Developer

Frameworks have always been built for human users. But today, AI has joined the development team as a new kind of developer.

SIcore chose not to hand AI tools designed for humans but to design from scratch with AI as a first-class user. Choosing vanilla is the answer to that question.

Series Recap

#	Topic	One-liner
01	Motivation	Beginner-friendly design turned out to be AI-friendly
02	Direct URL mapping	URL = class name. Zero routing config
03	JSON-only	Server never returns HTML
04	Mockup = implementation	Add a name attribute and the mockup becomes production code
05	Dynamic list rendering	Template row auto-expands array data
06	Custom HTML attributes	data-* attributes for common patterns
07	Map-based data design	No entities. Just Maps
08	Single-file CSS	400 lines covers an entire business app
09	Client-side data + JWT	Stateless design, no server sessions
10	SQL directly in Java	No XML. SQL injection protection built in
11	Why go vanilla? (this article)	The design philosophy behind it all

Laid out like this, every decision connects along one axis: adding nothing unnecessary. By not adding, the result became a framework that AI handles well and beginners can actually read.

Closing Thoughts

"Vanilla" sounds old-fashioned. Inefficient, maybe. But in practice, vanilla is a strength in the age of AI-assisted development.

Code that AI understands → higher generation accuracy
Code that beginners can read → junior devs become productive faster, with AI's help

Going vanilla isn't "old." It's a deliberate choice to add nothing unnecessary. A framework's value is defined not by what it adds, but by what it leaves out — that's the conclusion I reached after building this for the third time in ten years.

You can run the sample code directly in VS Code with just a browser. Setup instructions are in the README. If any of this sounds interesting, I'd love for you to give it a try.

SIcore Framework Links

All code and documentation is publicly available:

Website: https://onepg.com/
GitHub: https://github.com/sugaiketadao/sicore
How to verify sample screens (VS Code): https://github.com/sugaiketadao/sicore#%EF%B8%8F-how-to-verify-sample-screens---vs-code
Getting started with AI development: https://github.com/sugaiketadao/sicore#-getting-started-with-ai-development

Thanks for reading!
If you found this useful, reactions and comments are always appreciated. ❤️

Four Pagination Strategies for Enterprise Database Lists

sugaiketadao — Wed, 01 Apr 2026 14:07:43 +0000

Introduction

When implementing a paginated list screen in a business application, the first idea that comes to mind is usually "fetch rows with OFFSET/LIMIT."

But once you actually run it, the problems pile up fast: "The same row appeared again on the next page," "A record I saw earlier is gone," "Page 1000 takes forever to load." OFFSET/LIMIT alone can't solve all of these.

I've been adding pagination support to a Java framework I'm building from scratch, which prompted me to revisit and organize the options. This article walks through four pagination strategies I've actually used in enterprise projects, along with their trade-offs.

What Pagination Needs to Get Right

Before diving in, let's define what a solid pagination implementation should provide:

Correct data — no missing rows, no duplicates
Consistency — minimal interference from other users' updates
Acceptable DB load
User-controlled sort order

Two phenomena are worth calling out specifically:

Row shift — When another user inserts or deletes a row between page loads, rows that should appear on the next page are skipped, or rows from the previous page appear again.
Stale read — The list keeps showing snapshot data from the initial query and doesn't reflect updates made by other users during navigation.

Here's an example of row shift. You're viewing page 1 of 10 rows per page, then another user deletes ID:03:

                         Normal
--- When page 1 loads ---   →    --- When page 2 loads ---
ID: 01 (sort rank  1)             ID: 11 (sort rank 11)
ID: 02                            ID: 12
ID: 03                            ID: 13
    ...                               ...
ID: 10 (sort rank 10)             ID: 20

↓ Another user deletes ID:03 before page 2 loads:

--- When page 2 loads ---
ID: 12  ← ID:11 moved to page 1 due to the deletion; not shown on page 2
ID: 13
ID: 14
  ...
ID: 21

No single strategy perfectly satisfies every requirement — you'll always be choosing a trade-off based on your project's priorities.

When baking this into a framework, two additional constraints also matter:

Implementation transparency — simple enough to use without ceremony
DBMS portability — works across different database engines

Strategy 1: Per-Request DB Access — Row Number (OFFSET)

SELECT * FROM orders
ORDER BY id
LIMIT 10 OFFSET 20   -- page 3 (10 rows per page)

The simplest approach. Each page load tells the DB "give me M rows starting from row N."

Drawbacks

DBMS-specific syntax. Oracle uses FETCH FIRST N ROWS ONLY, MySQL uses LIMIT ... OFFSET, SQL Server uses OFFSET ... FETCH NEXT, and so on.
High DB load at large offsets. The DB must scan and skip all rows before the offset — the further you page, the more work it does.
Row shift occurs due to concurrent insertions or deletions. (See the diagram above.)

Strategy 2: Per-Request DB Access — Application-Side Scrolling

Instead of delegating the offset to the DB, the application reads from the beginning of the ResultSet and skips rows itself until it reaches the desired page.

Java implementation sketch (JDBC):

try (PreparedStatement ps = con.prepareStatement("SELECT * FROM orders ORDER BY id");
     ResultSet rs = ps.executeQuery()) {

    // Skip the first N rows in the application
    for (int i = 0; i < n; i++) {
        if (!rs.next()) {
            break;  // No more data
        }
    }

    // Collect M rows and return
    ...
}

Like Strategy 1, this queries the DB on every page load. But because no OFFSET is sent to the DB, the same code works across any DBMS.

Drawbacks

App-side processing cost grows with page depth. Viewing page 100 means skipping 990 rows in the application.
Row shift happens in the same way as Strategy 1.

Variation: Key-based cursor
If you store the last row's key value from the previous page and filter with WHERE id > :lastId, you can reduce the number of skipped rows and also mitigate row shift. The downside: changing sort order or jumping directly to an arbitrary page becomes difficult, and it's hard to encapsulate inside a framework.

Strategies 1 and 2 are in the "query the DB on every request" group. Strategies 3 and 4 belong to a different group: "query the DB once, then cache the result."

Strategy 3: Single DB Query — Work File Cache

On the first search, fetch all matching rows from the DB and write them to a file. Subsequent page loads read from that file.

[First load]  DB → fetch all rows → write to file → display page 1
[Later loads] read from file → display page N

Benefits

No DB access after the first load — low DB load for navigation
Consistency is guaranteed during navigation (no row shift)

Drawbacks

Stale reads occur. The list shows a snapshot from the initial query; updates by other users are not reflected during navigation.
Multi-server deployments are problematic. Files written on one web server aren't visible on others — shared or object storage is needed.
When do you delete the files? You need a cleanup strategy: on session end, on logout, after a timeout, etc.
Files multiply quickly. Each concurrent user creates their own file.
Large first-load queries can be heavy on memory and I/O (capping the result size helps).

Strategy 4: Single DB Query — Work Table Cache

On the first search, fetch all matching rows and INSERT them into a dedicated work table. Subsequent page loads SELECT from that table.

[First load]  DB → fetch all rows → INSERT into work table → SELECT from work table → display page 1
[Later loads] SELECT from work table → display page N

This is Strategy 3 with files replaced by a database table. The mechanics are essentially the same.

Benefits

Same consistency guarantee as Strategy 3 — no row shift
Works fine in multi-server setups. No need to worry about where files land.
Pagination is just INSERT + SELECT
Row numbers can be assigned at INSERT time, making direct page jumps straightforward

Drawbacks

Stale reads occur, just like Strategy 3.
When do you purge the work table? A periodic cleanup job or session-lifecycle integration is required.
Heavy concurrent usage bloats the work table. Each active user adds their own rows.
Each search type needs its own work table schema.

Comparison Summary

Per-Request DB Access (Strategies 1 & 2)

Other users' updates are reflected in real time (no stale reads), but row shift can occur.

	Strategy 1: OFFSET	Strategy 2: App-side scrolling
Load location	DB (OFFSET scan)	App (skip loop)
DBMS portability	Syntax varies by DBMS	Works with any DBMS
Row shift	Yes	Yes
Stale read	No	No

Single DB Query + Cache (Strategies 3 & 4)

The snapshot from the first query is preserved, so no row shift. But stale reads do occur.

	Strategy 3: Work file	Strategy 4: Work table
Pagination mechanism	File I/O	INSERT / SELECT
Multi-server support	Needs shared storage	No issue
Cleanup design needed	Yes	Yes
Row shift	No	No
Stale read	Yes	Yes

Which Strategy Fits Which Situation?

Situation	Recommended Strategy
Rarely updated reference data (master lists, etc.)	Strategy 1 (OFFSET) — simplest option
Workflows where minor row shift is acceptable	Strategy 1 or 2
DBMS without OFFSET support, or DBMS-agnostic requirement	Strategy 2 (app-side scrolling)
Consistency is critical (approval flows, reports, etc.)	Strategy 3 or 4
Multi-server deployment	Strategy 4 (work table)

Work file and work table strategies win on consistency, but the cleanup design adds non-trivial operational complexity.

Wrapping Up

That's a rundown of four pagination strategies. There's no universally "correct" answer — the right choice depends on your project's characteristics.

For my own framework, DBMS portability is a priority, so I'm leaning toward Strategy 2 (app-side scrolling) as the base implementation. But honestly, I'm still mulling it over. If you've handled pagination in a real project — or know of an approach I missed — I'd love to hear about it in the comments!

SIcore Framework Links

My custom framework is published here.

Website: https://onepg.com
GitHub: https://github.com/sugaiketadao/sicore
How to verify sample screens (VS Code): https://github.com/sugaiketadao/sicore#%EF%B8%8F-how-to-verify-sample-screens---vs-code
Getting started with AI development: https://github.com/sugaiketadao/sicore#-getting-started-with-ai-development

Check out the other articles in this series!

Thank you for reading!
I'd appreciate it if you could give it a ❤️!

When Is It OK to Build a System with AI Alone? A Framework for Thinking About Responsibility

sugaiketadao — Sat, 14 Mar 2026 09:28:45 +0000

Introduction

These days, "I built X with AI alone" posts are everywhere. For personal projects, it feels like this has become the new normal. Yet in professional software development (by which I mean contract-based system development for clients), I've never heard anyone say "we built it with AI alone."

So why, despite all the progress AI has made, do professional projects still not go "AI only"?

I want to nail down my own answer to this question now — so that when AI capabilities increase even further, I have a benchmark to revisit and ask: "Does that change anything?"

My conclusion: it comes down to responsibility.

Breaking Down "Responsibility"

A contract for system development cannot include a clause like: "Built entirely by AI, so humans accept no liability for bugs." (Deeply discounted, of course!)

So what does "responsibility" actually mean in a contract context? It breaks down into roughly three things:

Warranty period (free bug fixes) — The work of fixing bugs can involve AI. But the liability itself — handling damage claims or contract termination — can only be borne by humans.
The commitment to do everything possible when something goes wrong — Apologizing, coordinating, explaining preventive measures. Only humans can do this. AI cannot.
The resolve to minimize bugs as close to zero as possible — Even humans can't promise perfection. But a human can say "we will do our absolute best." AI famously cannot guarantee zero bugs, and everyone knows it.

In short: only humans can be held responsible — and that's the fundamental reason "AI only" is a step no one takes in professional development.

Systems Where AI Alone Is Dangerous

With that understanding of responsibility, these domains still require human involvement:

Domain	Why
Healthcare (diagnosis, medication, etc.)	Directly affects life and death. The cost of errors is too high.
Payments and finance	Financial damage can extend to third parties.
Legal documents between companies (invoices, purchase orders, etc.)	Legally binding. Errors affect relationships outside the organization.

The common thread: errors have direct, irreversible impacts on people or society. Using AI-generated output in these fields without human review is, in my view, still too risky at this point.

Systems Where AI Alone Is Fine

On the other hand, these kinds of systems have no significant barrier to being built AI-only:

Games
Bill-splitting calculators
Inventory trackers

The common thread: errors are limited in impact and easy to fix.

Summary

In professional contract work, the developer using AI is a human who holds the contract. Whether to use AI as a development tool is fundamentally up to the contractor's discretion — and the real question is whether humans can be accountable for the output.

AI is just a tool. No matter how capable the tool gets, the questions of what you build with it and who takes responsibility don't change. To put it bluntly: in a contract dispute, the worst case is court. AI cannot stand trial.

"Built entirely with AI" is something you can proudly say only when the impact of mistakes stays entirely within the maker's own sphere — that's my conclusion for now.

That said, even life-critical systems like autonomous vehicles are increasingly powered by AI. But they're not "AI alone" — they work because of strict legal frameworks, multiple layers of safety design, and a clear chain of human accountability. Which suggests: wherever that kind of structure can be built, AI adoption will follow.

Check out the other articles in this series!

Thank you for reading!
I'd appreciate it if you could give it a ❤️!

SQL Directly in Java — Why I Built a Java Framework (third attempt in 10 years) #10

sugaiketadao — Sat, 07 Mar 2026 16:06:09 +0000

Introduction

Over the years I've written SQL in XML files, embedded it in entity classes, and built it inline in Java. Each approach has trade-offs, but two pain points kept recurring:

Dynamic search conditions — the more conditions you add, the harder the XML <if> tags become to read
Batch processing performance — when INSERT/UPDATE runs inside a loop, you start worrying about PreparedStatement overhead

SIcore's answer is two SQL-building classes tailored to each use case:

SqlBuilder — assembles SQL dynamically (primarily for web service search queries)
SqlConst — defines SQL statically (primarily for batch processing)

This article introduces both and explains when to use each.

What This Article Covers

The friction of XML-based SQL management
SqlBuilder — how dynamic SQL assembly works
SqlConst — static SQL with type-safe binding
PreparedStatement caching with SqlConst
Combining with Java Text Blocks (""")

The Problem with XML-Based SQL

O/R mappers like MyBatis write SQL in XML files:

<select id="searchUsers" resultType="map">
  SELECT u.user_id, u.user_nm, u.email
  FROM t_user u
  WHERE 1=1
  <if test="userId != null and userId != ''">
    AND u.user_id = #{userId}
  </if>
  <if test="userNm != null and userNm != ''">
    AND u.user_nm LIKE '%' || #{userNm} || '%'
  </if>
  ORDER BY u.user_id
</select>

The content is readable enough, but several friction points appear before you can use it effectively:

SQL is separated into a different file (XML), making it hard to trace where it's used. On the Java side, mapping uses an ID string like searchUsers — renaming or deleting won't produce a compile error
You need to learn the XML tag syntax for <if test="..."> and friends
You constantly switch between the XML file and the Java class
The difference between #{} and ${} is a SQL injection trap — ${} embeds values directly

Dynamic SQL is where the friction really hits. The more conditions you add, the more tags pile up, and the harder the file becomes to read. And there's one more subtle annoyance: comparison operators like < and > must be written as XML entities (<, >) — easy to forget, and mildly infuriating every time.

SIcore takes a different approach: build SQL using a Java library with SQL injection protection built in.

SqlBuilder — Dynamic SQL Assembly

SqlBuilder assembles SQL and bind parameters together. It's designed for search queries in web services, where WHERE clause conditions are added only when the corresponding input has a value.

Basic Usage

final SqlBuilder sb = new SqlBuilder();
sb.addQuery("SELECT ");
sb.addQuery("  u.user_id ");
sb.addQuery(", u.user_nm ");
sb.addQuery(", u.email ");
sb.addQuery(" FROM t_user u ").addQuery(" WHERE 1=1 ");  // method chaining also works

// Add WHERE condition only if value is not blank
sb.addQnotB("   AND u.user_id = ? ", io.getString("user_id"));
sb.addQnotB("   AND u.user_nm LIKE '%' || ? || '%' ", io.getString("user_nm"));
sb.addQnotB("   AND u.email LIKE ? || '%' ", io.getString("email"));
sb.addQnotB("   AND u.income_am >= ? ", io.getBigDecimalNullable("income_am"));
sb.addQnotB("   AND u.birth_dt = ? ", io.getDateNullable("birth_dt"));

sb.addQuery(" ORDER BY u.user_id ");

// Execute the query
final IoRows rows = SqlUtil.selectBulk(getDbConn(), sb, 5);

addQnotB (Query if not Blank) skips the SQL fragment when the parameter is null or blank. That's the core of dynamic SQL assembly here.

Unlike XML's <if test="...">, the code looks the same regardless of which conditions are active. addQuery and addQnotB just line up uniformly — the SQL structure is readable directly from the code.

When complex branching is needed, you're not locked into addQnotB. You can mix in regular Java if statements with addQuery. Because it's standard Java code, it's easy to debug and easy for AI to parse.

Bind variables (?) are always used, so SQL injection is not a concern.

Variable-Length IN Clauses

Writing an IN clause in MyBatis requires the <foreach> tag, which surprises many developers. With addListInBind, you just pass a list and the placeholders expand automatically:

final List<Object> statusList = new ArrayList<>();
statusList.add("A");
statusList.add("B");
statusList.add("C");

sb.addQuery(" AND u.status_cs IN (");
sb.addListInBind(statusList);
sb.addQuery(")");
// Generated SQL: AND u.status_cs IN (?,?,?)
// ? expands to match list size; each value is passed as a bind parameter

Key Methods

Method	Description
`addQuery(sql)`	Append SQL only
`addQuery(sql, params...)`	Append SQL and parameters (multiple params allowed)
`addQnotB(sql, param)`	Append SQL and parameter only if param is not null/blank
`addParams(params...)`	Append parameters only
`addListInBind(list)`	Append variable IN clause placeholders and parameters
`addSqlBuilder(other)`	Merge another SqlBuilder into this one

SqlConst — Static SQL Definition

SqlConst defines fixed, immutable SQL. It shines in batch processing where the same SQL runs repeatedly.

Basic Usage (Declare as a Class Field)

private static final SqlConst SQL_INS_USER = SqlConst.begin()
    .addQuery("INSERT INTO t_user ( ")
    .addQuery("  user_id ")
    .addQuery(", user_nm ")
    .addQuery(", email ")
    .addQuery(", income_am ")
    .addQuery(", birth_dt ")
    .addQuery(" ) VALUES ( ")
    .addQuery("  ? ", "user_id",   BindType.STRING)
    .addQuery(", ? ", "user_nm",   BindType.STRING)
    .addQuery(", ? ", "email",     BindType.STRING)
    .addQuery(", ? ", "income_am", BindType.BIGDECIMAL)
    .addQuery(", ? ", "birth_dt",  BindType.DATE)
    .addQuery(" ) ")
    .end();

You chain calls from begin(), building SQL and bind definitions together, then call end() to produce an immutable SqlConst object. Declared as static final, it's built once at application startup.

Bind Types (BindType)

The mapping between SQL columns and bind types is declared explicitly:

BindType	SQL Type	Java Type
`STRING`	VARCHAR and other strings	`String`
`BIGDECIMAL`	INTEGER, NUMERIC, DECIMAL and other numerics	`BigDecimal`
`DATE`	DATE (yyyyMMdd format)	`java.sql.Date`
`TIMESTAMP`	TIMESTAMP (yyyyMMddHHmmssSSS format)	`java.sql.Timestamp`

When bind(io) is called, values are retrieved and converted using the corresponding io method for each BindType: getString, getBigDecimal, getDate, and getTimestamp.

Binding at Runtime

At execution time, bind(io) extracts values from a parameter map and produces a bound SqlBean:

// Extract values from io (map), bind them, and execute
SqlUtil.executeOne(getDbConn(), SQL_INS_USER.bind(io));

Internally, bind() pulls values from the map in the order declared at definition time, converting each to the declared type. The order and types guaranteed at declaration time are enforced at runtime — type mismatches and ordering errors are managed in the code itself.

PreparedStatement Caching with SqlConst

When INSERT/UPDATE runs inside a batch loop, the normal executeOne creates and destroys a PreparedStatement on every call. executeOneCache (or executeCache) caches and reuses the PreparedStatement, improving performance:

@Override
protected void doExecute(final IoItems io) throws Exception {
  // Read CSV row by row and UPSERT
  try (final CsvReader cr = new CsvReader(inputPath, CharSet.UTF8, CsvType.DQ_ALL_LF)) {
    for (final IoItems row : cr) {
      // Try UPDATE; if 0 rows affected, INSERT (UPSERT)
      if (!SqlUtil.executeOneCache(getDbConn(), SQL_UPD_USER.bind(row))) {
        SqlUtil.executeOneCache(getDbConn(), SQL_INS_USER.bind(row));
      }
    }
  }
}

The cache is held per DbConn instance. When the connection closes, the cache is released.

Method	Return	Description
`executeOne(conn, sb)`	`boolean`	Normal execution. `true` for 1 row, `false` for 0, exception for multiple
`executeOneCache(conn, sb)`	`boolean`	Cached execution. `SqlConst` only
`execute(conn, sb)`	`int`	Normal execution. Returns row count
`executeCache(conn, sb)`	`int`	Cached execution. Returns row count

SqlBuilder (dynamic SQL) is not eligible for caching because the SQL string changes on every call. Caching only makes sense for fixed SQL like SqlConst.

Can't MyBatis Cache Too?

MyBatis-style frameworks do support PreparedStatement caching. However, the mechanism is different.

Caching depends on the JDBC driver and its defaults vary by environment — MySQL Connector/J defaults to off (cachePrepStmts=true required), while PostgreSQL defaults to on per connection. Even when enabled, there's no way to see from code which SQL statements are cached, and dynamic SQL may end up cached unnecessarily.

SIcore's executeOneCache lets you explicitly nominate which SQL to cache at the application level. It works consistently across any JDBC driver, and reading the code alone tells you "this SQL is cached and reused."

Combining with Java Text Blocks

Java 15+ Text Blocks (""") let you write multi-line SQL strings naturally.

With SqlBuilder:

sb.addQuery("""
    SELECT
      u.user_id
    , u.user_nm
    , u.email
    FROM t_user u
    WHERE 1=1
    """);
sb.addQnotB("   AND u.user_id = ? ", io.getString("user_id"));

With SqlConst:

private static final SqlConst SQL_INS_USER = SqlConst.begin()
    .addQuery("""
        INSERT INTO t_user (
          user_id
        , user_nm
        , email
        , income_am
        , birth_dt
        ) VALUES (
        """)
    .addQuery("  ? ", "user_id",   BindType.STRING)
    .addQuery(", ? ", "user_nm",   BindType.STRING)
    .addQuery(", ? ", "email",     BindType.STRING)
    .addQuery(", ? ", "income_am", BindType.BIGDECIMAL)
    .addQuery(", ? ", "birth_dt",  BindType.DATE)
    .addQuery(" ) ")
    .end();

Separating the SQL block from the bind-definition lines keeps readability high while maintaining type-safe binding.

Note: the framework requires Java 11+, so confirm your project's Java version before adopting Text Blocks.

SqlBuilder vs SqlConst — When to Use Which

	SqlBuilder	SqlConst
SQL nature	Dynamic (changes by condition)	Static (fixed)
Primary use	Web service search queries	Batch INSERT/UPDATE
Bind type declaration	Not required (pass as Object)	Required (explicit BindType)
PS caching	Not supported (SQL changes per call)	Supported (`executeOneCache`)
Declaration location	Inside methods	`static final` class field

The rule is simple: dynamic conditions → SqlBuilder, fixed SQL → SqlConst.

SqlUtil also provides methods like insertOne, updateOne, and deleteOne that generate INSERT/UPDATE/DELETE SQL automatically from database metadata — just pass the table name and IoItems. These cover simple single-record operations without writing SQL at all.

Closing Thoughts

Both SqlBuilder and SqlConst ultimately produce a SqlBean (SQL string + parameter list) and hand it to SqlUtil — the same interface. The calling code doesn't change. This consistency is what makes the dynamic/static split feel natural rather than awkward.

Writing SQL in Java also means XML syntax to learn disappears, and SQL, conditions, and bind values all live in the same file. The code flow is straightforward to follow.

That advantage extends to AI-assisted development. In XML-based approaches, AI reading your Java code has to also load the XML file and interpret its tag syntax before understanding the query. With Java-inline SQL, SQL, branching, and bind values all live in the same file — one file read is enough to understand the entire operation, which leads to more accurate completions and refactoring suggestions.

Code Examples

SqlBuilder example: https://github.com/sugaiketadao/sicore/blob/main/src/com/example/app/service/exmodule/ExampleListSearch.java
SqlConst example: https://github.com/sugaiketadao/sicore/blob/main/src/com/example/app/bat/exmodule/ExampleImport.java
Auto-generated SQL example: https://github.com/sugaiketadao/sicore/blob/main/src/com/example/app/service/exmodule/ExampleUpsert.java

Check out the other articles in this series!

01 Why I Built a Java Framework
02 Direct URL-to-Class Mapping
03 JSON-Only Communication
04 Mockup = Implementation
05 Dynamic List Rendering
06 Custom HTML Attributes
07 Map-Based Design
08 Single-File CSS Design
09 Client-Side Data Management and JWT Auth
10 SQL Directly in Java (this article)
11 Why Go Vanilla?

SIcore Framework Links

All implementation code and documentation are available here:

Website: https://onepg.com
GitHub: https://github.com/sugaiketadao/sicore
How to verify sample screens (VS Code): https://github.com/sugaiketadao/sicore#%EF%B8%8F-how-to-verify-sample-screens---vs-code
Getting started with AI development: https://github.com/sugaiketadao/sicore#-getting-started-with-ai-development

Thank you for reading!
I'd appreciate it if you could give it a ❤️!

Client-Side Data Management - Why I Built a Java Framework (third attempt in 10 years) #09

sugaiketadao — Sat, 07 Mar 2026 04:58:54 +0000

Introduction

If you've ever built business web applications, you've probably hit these friction points:

Passing large amounts of data between pages — do you really need to round-trip through the server?
Server-side sessions are heavy — resource consumption, session sharing across scaled-out nodes, timeout management…
Building an auth system from scratch is painful — LDAP integration, JWT issuance and validation, deciding where to store tokens…

This article presents three design approaches that tackle these problems together:

Scoped browser storage — pass data between pages safely, organized by URL scope
JS-variable session management — client-side session that auto-syncs with the server
Transparent JWT authentication — LDAP + JWT with zero authentication code in business logic

These three are tightly coupled. Combined, they produce a state where no auth or data-management code leaks into your business layer.

1. Scoped Browser Storage — Let Directory Structure Be Your Scope

The Problem: Page-to-Page Data Passing Gets Messy

Without a single-page app, every page transition requires a data handoff. Common approaches and their drawbacks:

Approach	Problem
URL parameters	Explodes in length with many fields. Timestamps and binary data are awkward.
Hidden fields	Embedded in HTML, hard to manage. Accidentally receiving stale data is easy. Detail lists are especially painful.
Cookies	Size-limited. Sent to the server on every request.
Raw `sessionStorage`	Keys collide easily. No way to tell which page's data is which.

The Solution: URL-Scoped Storage

Rather than using sessionStorage directly, SIcore wraps it with automatic scope detection derived from the URL path.

Scope	Purpose	Example
Page scope	Data valid only within the current page	Temporary search conditions
Module scope	Shared across pages in the same directory	Passing header data to a detail-edit page
System scope	Shared across the entire application	User preferences

/app/exmodule/head-edit.html    →  module key: "/app/exmodule/"
/app/exmodule/detail-edit.html  →  module key: "/app/exmodule/"  ← same!

Pages in the same directory automatically share data. There's no naming convention to memorize — your directory layout is your scope design.

How It Works in SIcore

SIcore provides the StorageUtil class for this.

Header edit page (head-edit.js):

// Save the whole form to storage, then navigate to the next page
const headObj = PageUtil.getValues();
StorageUtil.setModuleObj('headData', headObj);
HttpUtil.movePage('detail-edit.html');

Detail edit page (detail-edit.js):

// Retrieve from storage and populate the form
const headObj = StorageUtil.getModuleObj('headData');
PageUtil.setValues(headObj);

The caller doesn't need to know which page stored the data. As long as both pages live in the same module directory, data is naturally shared. The actual storage key becomes something like _module@/app/exmodule/headData — the scope and URL path are injected automatically, so different modules never collide.

Benefits

No key collisions — scopes are automatically isolated
Directory design = data design — split by feature directory and scopes fall into place
No URL parameters needed — works cleanly regardless of field count

2. JS-Variable Session Management — Auto-Sync With the Server

Session data is held in JavaScript variables, not in localStorage or sessionStorage. A page reload clears it — and that turns out to be a security feature, not just a limitation.

The Problem: Server-Side Sessions Are Heavy

Traditional server-side sessions (HttpSession, etc.) come with known costs:

Consume server memory (OutOfMemoryError is a real concern at scale)
Require session sharing mechanisms when scaling horizontally
Need timeout management and cleanup logic

The Solution: JS Variables + Automatic Sync

SIcore stores session data in a JS variable and automatically sends and receives it under the reserved _session key on every server call.

// Inside the framework's server-call logic (simplified)

// Before sending the request: attach session data automatically
req['_session'] = sessionData;

// After receiving the response: update session data automatically
sessionData = res['_session'];

On the server side, business code simply reads from and writes to the _session key in the JSON. The server holds no session state — it's entirely client-driven.

When to Use Storage vs. JS-Variable Session

	Browser Storage	JS-Variable Session
Where stored	`sessionStorage`	JS variable
Server sync	None	Auto-synced on every call
Survives reload	Yes	No — cleared on reload
Use for	Page-to-page data handoff	Data shared with the server

If you want to carry data between pages, use storage. If you want data shared with the server, use session. The distinction is clear.

Benefits

Stateless server — no session state on the server side; easy horizontal scaling
Clean business code — the framework handles sync; business code never thinks about it
Clears on reload — JS variables vanish on page refresh; nothing lingers in storage, which is a security advantage

3. Transparent JWT Authentication — Business Code Doesn't Know Auth Exists

Building auth from scratch — LDAP integration, JWT issuance and validation, choosing where to store tokens — is genuinely tedious. SIcore isolates authentication into three layers, hiding it completely from business code.

Layer	Responsibility	Business code involvement
Sign-in	LDAP auth → JWT issuance → store in JS variable	Sign-in page only
Token management	Hold token in JS variable; attach automatically to every request	None
Server validation	Validate JWT on every request; return 401 on failure	None

Business pages call the server with zero authentication code.

Full Flow

At sign-in:

[Browser] User enters ID and password on the sign-in page
     ↓
[Server] Authenticate via LDAP → issue JWT on success
     ↓  Response JSON: { _session: { token: "hoge..." } }
[Browser] Receive _session.token
     ↓  Store token in JS variable
[Browser] Navigate to the business page

All subsequent business operations (fully automatic):

[Browser] Business page calls callJsonService() — no auth code
     ↓  Framework automatically adds: Authorization: Bearer hoge...
[Server] Validate JWT → success → run business logic → return response

Why Store the Token in a JS Variable?

localStorage and sessionStorage persist the token across page reloads, eliminating the need to re-authenticate. But both are readable by scripts via XSS attacks.

Storing in a JS variable means the user re-authenticates on every reload — but it also eliminates the token theft vector that persisted storage introduces.

In typical business app usage, page reloads are rare during normal operation. And in SI project environments, "closing the browser signs you out" is often the expected behavior — many clients prefer it that way.

Server-Side JWT Validation (Java)

// AbstractHttpHandler.java (excerpt)
private boolean validateJwt(final HttpExchange exchange) {
  final String authHeader = exchange.getRequestHeaders().getFirst("Authorization");
  if (authHeader == null || !authHeader.startsWith("Bearer ")) {
    return false;
  }
  JwtUtil.validateToken(authHeader.substring(7));
  return true;
}

Sign-in service (Java) — LDAP auth → JWT issuance:

// SigninService.java (excerpt)
try {
  (new InitialDirContext(param)).close(); // LDAP authentication
} catch (final NamingException e) {
  io.session().put("token", ValUtil.BLANK);
  io.putMsg(MsgType.ERROR, "es001");
  return;
}
final String token = JwtUtil.createToken(id);
io.session().put("token", token);

Automatic token attachment (JavaScript) — business code is not involved:

// Inside the framework's server-call logic (simplified)
const token = SessionUtil._token;
if (!ValUtil.isBlank(token)) {
  header['Authorization'] = 'Bearer ' + token;
}

Benefits

Clean business code — token management, header injection, and 401 handling are all transparent
XSS resistance — no persisted token in storage means no storage-based token theft
Stateless — JWT-based; no server-side session required

Conclusion

Here's a summary of the three approaches:

Approach	Problem	Solution	Benefit
Scoped storage	Messy page-to-page data passing	Auto-detect scope from URL path	No key collisions; directory = scope
JS-variable session	Heavy server-side sessions	Client-side JS variable + auto-sync	Stateless server; easy scaling
Transparent JWT auth	Auth boilerplate is painful	Layer separation; hidden from business code	Clean code; XSS resistance

All three share the same philosophy: keep business code free from infrastructure concerns. Data management, session sync, and authentication are all handled by the framework layer — so you can stay focused on the actual business logic.

Check out the other articles in this series!

01 Why I Built a Java Framework
02 Direct URL-to-Class Mapping
03 JSON-Only Communication
04 Mockup = Implementation
05 Dynamic List Rendering
06 Custom HTML Attributes
07 Map-Based Design
08 Single-File CSS Design
09 Client-Side Data Management and JWT Auth (this article)
10 SQL Directly in Java
11 Why Go Vanilla?

SIcore Framework Links

All implementation code and documentation are available here:

Website: https://onepg.com
GitHub: https://github.com/sugaiketadao/sicore
How to verify sample screens (VS Code): https://github.com/sugaiketadao/sicore#%EF%B8%8F-how-to-verify-sample-screens---vs-code
Getting started with AI development: https://github.com/sugaiketadao/sicore#-getting-started-with-ai-development

Thank you for reading!
I'd appreciate it if you could give it a ❤️!

What I Learned Developing a Custom Framework with Generative AI

sugaiketadao — Mon, 23 Feb 2026 04:35:12 +0000

Introduction

Since around the summer of 2025, I've been building a business application framework for Japan's SI industry as a personal project. From the very start, I fully adopted GitHub Copilot (generative AI) as a development partner.

In this article, I'll share what I experienced while coding alongside generative AI — the fun moments, the frustrating ones, and the surprising discoveries.

My development style: I write the code myself and have the AI review it. Rather than having AI generate everything, I use it as a reviewer for code I've already written.

The Joy of Being Code-Reviewed After 20 Years

For nearly 20 years, I've always been on the giving side of code reviews. I had no opportunity to have my own code reviewed.

When you show your code to AI, it genuinely reviews it. And it lavishes you with praise. "This design is excellent," "This is enterprise-level" — being on the receiving end of a review after 20 years was a genuinely fun experience.

My wife also chats with the AI (she calls it "Chad") and says it always praises her too. Maybe it has a "praise to encourage" policy?

Of course it doesn't just compliment you — it also suggests improvements. The catch is that those suggestions are occasionally wrong (more on that below).

Strong with Common Specs — Tool Creation at Warp Speed

AI shines brightest when working with widely known specifications and formats.

During this framework project, I needed a tool to parse JavaDoc source and generate an HTML reference in a custom format. Since JavaDoc syntax is a well-known spec, I described the requirements and the AI wrote working code from parser to HTML generation almost immediately. It's the same principle as "make me a Tetris game" — the more public the spec, the higher the AI's generation accuracy.

On the flip side, accuracy drops with specs the AI doesn't know about, like the custom APIs of a homegrown framework — and worse, it starts confidently using methods that don't exist.

Using Non-Existent Methods with Full Confidence

With popular frameworks like Spring or React, AI can work correctly because it's been trained on massive amounts of data. But a custom framework's API simply doesn't exist in that training data. The result: it generates code that calls non-existent methods as if they already exist — not creating new methods, but treating them as established API calls.

This is the infamous phenomenon known as hallucination.

As a countermeasure, I added to copilot-instructions.md (GitHub Copilot's project-specific instruction file): "Do not use methods that don't exist in the API reference." But it still happened. When I pressed the AI on it, it replied: "Because you didn't write 'absolutely must not.'" (Give me a break 👋)

I later found out the AI model I was using had a relatively high creativity setting (temperature). For code generation, choosing a precision-focused model is crucial. Now I explicitly list it under "Absolutely Prohibited" in copilot-instructions.md and enforce a workflow that pre-loads the API reference document.

Wrong Suggestions and "I'm Sorry"

AI occasionally gives incorrect feedback. And when you say "Please check again," it initially insists it was right. After the second or third time asking, it finally admits the mistake and says "I'm sorry" — which was honestly amusing.

Here's a concrete example. The following is an implementation for thread-safe log output:

@Override
public void println(final String line) {
  // Store in cache first, then output
  this.lineCache.offer(ValUtil.nvl(line));
  if (this.isPrinting.compareAndSet(false, true)) {
    try {
      // Switch to printing mode and flush cache
      cachePrint();
    } finally {
      // Reset flag even if an exception occurs
      this.isPrinting.set(false);
    }
  }
}

/**
 * Cache output (serial).
 */
private synchronized void cachePrint() {
  // Only output what's cached at this moment.
  // Stop after current size to avoid long-running loops.
  final int cacheSize = lineCache.size();
  for (int i = 0; i < cacheSize; i++) {
    final String cache = this.lineCache.poll();
    if (cache == null) {
      break;
    }
    super.println(cache);
  }
}

ConcurrentLinkedQueue for cache storage, AtomicBoolean for exclusion control, synchronized for serialization — a fully thread-safe design. But no matter how many times I asked, the AI kept insisting "This will error with multiple threads."

It eventually acknowledged my design was correct, but if I had blindly followed its advice, I would have broken working code. You need to think for yourself: "Is that really true?" when the AI makes a claim.

Same Instruction, Different Results

This framework maintains both a Japanese-commented source and an English-commented source (the Java logic is identical). I once gave the same modification instruction to both. The result: different code.

It seems that the presence of Japanese vs. English comments subtly shifts the AI's interpretation and code generation tendencies. In the end, I settled on a workflow: modify the Japanese source first, copy it, then have the AI translate only the JavaDoc portions into English. Even with the same instruction, changing the context changes the result — don't expect too much reproducibility.

Adopting a Reverse Proposal from the AI

I use development documents for both human readers and AI. Documents contain things like design rationale and background ("why we built it this way") — useful for humans, but irrelevant for code generation.

While experimenting with copilot-instructions.md, the AI proposed: "Why not add markers to skip human-facing supplementary content? It would reduce token consumption." I thought it was a great idea and adopted it.

<!-- AI_SKIP_START -->
(Design rationale, benefits, and other human-facing supplementary content goes here)
<!-- AI_SKIP_END -->

With an instruction in copilot-instructions.md to "skip sections surrounded by these markers," the AI skips that content and focuses on the parts relevant to code generation.

Actual document using this: https://sugaiketadao.github.io/sicore/02-develop-standards/11-web-service-structure.md

Another adopted proposal: create a AI-only reference that extracts just method names and signatures from the full JavaDoc. Humans need detailed documentation with descriptions and examples, but AI only needs to know "which methods exist." A streamlined AI-only reference reduced token consumption while also preventing hallucinations of non-existent methods.

Human JavaDoc: https://sugaiketadao.github.io/sicore/11-api-references/11-javadoc

AI JavaDoc: https://sugaiketadao.github.io/sicore/31-ai-api-references/11-java-doc.md

Eventually: Full Feature Generation in One Shot

After all that trial and error, I finally reached the point where I could have AI generate an entire feature (UI + server logic) on a custom framework from a single prompt:

HTML (screen layout, input forms)
JavaScript (UI event handling, validation, server communication)
Java (web service, DB operations, business logic)

What made it possible: maintaining copilot-instructions.md, establishing the API reference loading workflow, and documenting coding patterns. Building the system to communicate correctly with AI is the real essence of AI-assisted development.

Conclusion

After developing with AI, my takeaway is: AI is excellent but not omnipotent.

Praise feels nice, but don't take suggestions at face value
Hallucinations are inevitable
Preparation to communicate clearly (instructions, references, pattern docs) determines outcomes
Treat AI as an equal development partner

If you're interested in the approach of "making a framework AI-development-ready," please check out this framework (SIcore). It includes everything you need for AI-assisted development: prompt examples, AI references, and coding patterns — all included.

SIcore Framework Links

All implementation code and documentation are available here:

Website: https://onepg.com
GitHub: https://github.com/sugaiketadao/sicore
How to verify sample screens (VS Code): https://github.com/sugaiketadao/sicore#%EF%B8%8F-how-to-verify-sample-screens---vs-code
Getting started with AI development: https://github.com/sugaiketadao/sicore#-getting-started-with-ai-development

Check out the other articles in this series!

Thank you for reading!
I'd appreciate it if you could give it a ❤️!

Single-File CSS Design - Why I Built a Java Framework (third attempt in 10 years) #08

sugaiketadao — Sun, 22 Feb 2026 11:09:41 +0000

Introduction

In previous articles I covered the Java and JavaScript side of SIcore. This time, it's all about CSS.

Have you ever spent hours fighting a CSS framework just to apply your own design? You add !important, crank up selector specificity, and still lose — all because the framework's defaults are baked in too deep.

In Java and JavaScript, "correct" is largely objective. In CSS, there is no single correct answer — design varies from project to project. Adopting a large CSS framework means inheriting someone else's design decisions, and every time your project's look diverges from those defaults, you end up in an override war.

SIcore takes the opposite approach: start small and build only what you need. The entire styling for a business application is covered by a single CSS file of about 400 lines. This article explains the philosophy and structure behind that design.

What This Article Covers

Why "start minimal" makes sense for business apps
What one file covers
12-column grid and 3-stage responsive behavior
Unified form element styling
CSS custom properties for project-wide customization

Why Start Minimal?

The biggest cost of adopting a CSS framework isn't the file size — it's learning what is where, combined with a cost that is unique to CSS: inheriting someone else's design decisions.

Bootstrap's button border-radius is 4px or 6px — irrelevant to your project, yet it exists as a "default" that you must override. Tailwind CSS avoids the override problem with utility classes, but changing colors or sizes requires editing tailwind.config.js and running a build. One framework forces overrides; the other forces builds. Either way, you're adapting to the framework's rules rather than your own.

Starting minimal avoids this entirely:

① No upfront learning curve — You understand everything as you use it, gradually building a full picture.

② All design decisions are yours — No "override something I never asked for" situations.

③ AI-friendly — The entire file can be read in one pass before generating HTML, eliminating the risk of hallucinated class names.

④ No build tools, no dependencies — No Sass, PostCSS, or Tailwind pipeline. Just an editor and browser DevTools.

What One File Covers

"Starting minimal" doesn't mean leaving things out. onepg-base.css covers everything a business application screen needs:

Feature	Details
CSS Reset	Unified `box-sizing`, font inheritance
Page Layout	Fixed header/footer, fluid main content
Grid Layout	12-column system
Responsive	3 breakpoints: PC, tablet, smartphone
Form Elements	Text, select, checkbox, radio, button
Table	Borders, striped rows
Utilities	Text alignment, alert colors, link-style buttons
Item Highlight	Warning/error background colors

Bootstrap is roughly 10,000 lines. Tailwind's output varies but reaches thousands of lines for a typical project. When you keep only what a business app actually uses, 400 lines is enough.

12-Column Grid and Responsive Behavior

Place a label in item-head and an input element in item-body. On PC, they render side by side. Arrange grid-col-N divs so the N values sum to 12 — the same 12-column layout familiar from Bootstrap.

<div class="grid-row">
  <div class="grid-col-3">
    <div class="item-head"><label>Full Name</label></div>
    <div class="item-body"><input type="text" name="user_nm"></div>
  </div>
  <div class="grid-col-3">
    <div class="item-head"><label>Country</label></div>
    <div class="item-body"><select name="country_cs">...</select></div>
  </div>
  <div class="grid-col-6">
    <div class="item-head"><label>Email</label></div>
    <div class="item-body"><input type="text" name="email"></div>
  </div>
</div>

Two media queries produce three layout stages:

PC (side by side): Label and input render horizontally. The example above shows a 3-column layout.

|     grid-col-3    |     grid-col-3    |              grid-col-6                 |
| Full Name [_____] | Country [______▼] | Email [_______________________________] |

Tablet (stacked within columns): Column widths are preserved, but the label stacks above the input inside each column.

| Full Name  | Country    | Email                           |
| [_________]| [_______▼] | [_____________________________] |

Smartphone (full-width stack): All columns expand to full width, resulting in a single-column vertical layout.

Full Name
[_________]
Country
[_______▼]
Email
[_____________________________]

Unified Form Element Styling

Business apps display large numbers of text boxes, select boxes, and buttons side by side. SIcore unifies their height, border, border-radius, padding, and focus style across all form elements so the screen looks consistent without per-element overrides. Disabled and focused states are also covered by default — no extra work needed.

Validation error highlights are applied automatically by the JavaScript framework, using dedicated CSS classes. See the CSS class reference for details on each class.

CSS Custom Properties for Project-Wide Customization

All style values (colors, sizes, spacing) are consolidated in CSS custom properties (:root). Changing the color scheme for a new project is a single block of variable overrides — no hunting through scattered selectors.

Variable names follow the convention --onepg-base--category--purpose, so the intent is clear from the name alone. See the CSS class reference for the full list.

Conclusion

When you enumerate only the styles a business app actually needs, 400 lines turns out to be surprisingly sufficient.

CSS is where design gets personal, far more so than Java or JavaScript. That's exactly why starting minimal matters most in CSS — you keep every design decision in your own hands. Start small, grow only what you need. This approach is especially effective in SI projects and AI-assisted development.

A single 400-line file, simple class names, zero build steps. Read it once and you'll likely think: "I can customize this."

The files are available here:

CSS file (including grid media queries): https://github.com/sugaiketadao/sicore/blob/main/pages/lib/css/onepg-base.css
CSS class reference: https://sugaiketadao.github.io/sicore/11-api-references/02-cssdoc/

Check out the other articles in this series!

01 Why I Built a Java Framework
02 Direct URL-to-Class Mapping
03 JSON-Only Communication
04 Mockup = Implementation
05 Dynamic List Rendering
06 Custom HTML Attributes
07 Map-Based Design
08 Single-File CSS Design (this article)
09 Client-Side Data Management and JWT Auth
10 SQL Directly in Java
11 Why Go Vanilla?

SIcore Framework Links

All implementation code and documentation are available here:

Website: https://onepg.com
GitHub: https://github.com/sugaiketadao/sicore
How to verify sample screens (VS Code): https://github.com/sugaiketadao/sicore#%EF%B8%8F-how-to-verify-sample-screens---vs-code
Getting started with AI development: https://github.com/sugaiketadao/sicore#-getting-started-with-ai-development

Thank you for reading!
I'd appreciate it if you could give it a ❤️!

Map-Based Design - Why I Built a Java Framework (third attempt in 10 years) #07

sugaiketadao — Thu, 12 Feb 2026 12:29:47 +0000

Introduction

This time, I'll cover "Map-Based Design," which is at the core of SIcore's Java code architecture.

As introduced in previous articles, SIcore uses "JSON-only communication." In the flow Browser → JSON → Java → JSON → Browser, we use the Map-based Io class as the Java-side data container. Since JSON is an associative array (key-value pairs), receiving it as a Map on the Java side is the most natural approach.

In SIcore, this Io class handles all requests, responses, and database operations, without using Entity (Bean) classes. This commitment enables reduced code volume, unified field naming, and strong compatibility with AI.

What This Article Covers

What Map-based design is
Why we use Map for everything
Unified naming strategy
Type-safe and null-safe data retrieval
Bug prevention features
Deep copy safety
Benefits / Drawbacks

What is Map-Based Design?

On SIcore's server side (Java), all requests, responses, and database operations are handled with the Io class (a class that extends Map).

public void doExecute(final Io io) throws Exception {
  // Retrieve values from request (key-based access)
  String userId = io.getString("user_id");
  BigDecimal incomeAm = io.getBigDecimal("income_am");

  // Set database extraction result as response
  IoItems row = SqlUtil.selectOne(getDbConn(), sb);
  io.putAll(row);

  // The io object becomes the response as-is
}

No Entity (Bean) classes are created. There's no need to prepare classes like UserEntity or OrderDto for each table or screen.

Why We Use Map for Everything

In SIcore, the entire process from browser to database uses Map (Io class).

[Browser]  JSON  →  [Java] Io(Map)  →  [DB] SQL
                  ←  [Java] Io(Map)  ←

Web Page Data is "Text"

Input values on web pages are all strings (String), even if they appear to be numbers or dates.

<!-- Appears as numbers or dates on the browser, but... -->
<input type="text" name="income_am" value="1200000">
<input type="text" name="birth_dt" value="20250101">

These remain strings throughout the journey JavaScript → JSON → Java. Type conversion is only needed at the moment you use them in business logic.

Also, numeric and date fields can have empty (blank) values. Storing as strings preserves empty values as-is, avoiding conversion errors that occur when Beans receive them as int or LocalDate.

The Io class stores everything internally as strings (String) and retrieves them with type conversion as needed.

// Retrieve as string
String incomeAmStr = io.getString("income_am"); // "1200000"

// Retrieve with type conversion when needed
BigDecimal incomeAm = io.getBigDecimal("income_am"); // 1200000
LocalDate birthDt = io.getDateNullable("birth_dt");  // 2025-01-01

What Increases When You Create Beans

Imagine a business system with 50 tables and 30 screens.

Entity classes per table × 50
Form / DTO classes per screen × 30 (or more)
Entity ⇔ DTO conversion logic
Camel case conversion (user_id → userId)
Reflective getter / setter invocations

If you use Map for everything, all of these become unnecessary.

Same Approach as JavaScript

JSON, JavaScript associative arrays, and Java Maps all share the same structure: "access by key."

// JavaScript
const userId = req['user_id'];

// Java (Io class)
String userId = io.getString("user_id");

Data handling is unified from front to back.

Unified Naming Strategy

Database physical field name = HTML name attribute = Java Map key are unified.

-- Database
CREATE TABLE t_user (
  user_id VARCHAR(10),
  user_nm VARCHAR(50),
  income_am NUMERIC(10),
  birth_dt DATE
);

<!-- HTML -->
<input name="user_id">
<input name="user_nm">
<input name="income_am">
<input name="birth_dt">

// Java
String userId = io.getString("user_id");
String userNm = io.getString("user_nm");

Direct SQL Usage

Since field names are unified, Map data can be used directly in SQL.

public void doExecute(final Io io) throws Exception {
  // io contents (request JSON as-is)
  // {
  //   "user_id"   : "U001",
  //   "user_nm"   : "Mike Davis",
  //   "income_am" : "1200000",
  //   "birth_dt"  : "20250101"
  // }

  SqlUtil.insertOne(getDbConn(), "t_user", io);
  // ↑ Key names = DB field names, so it becomes an INSERT statement directly

  // SQL executed:
  // INSERT INTO t_user (user_id, user_nm, income_am, birth_dt)
  //   VALUES ('U001', 'Mike Davis', 1200000, 2025-01-01)
  // ※SqlUtil automatically determines column types from DB metadata and binds with appropriate types
}

Database retrieval to response display works the same way. SELECT results can be used directly for screen display.

public void doExecute(final Io io) throws Exception {
  // Retrieve extraction key from request
  SqlBuilder sb = new SqlBuilder();
  sb.addQuery("SELECT * FROM t_user WHERE user_id = ", io.getString("user_id")); // "user_id": "U001"
  // Database extraction (result is IoItems = Map)
  IoItems row = SqlUtil.selectOne(getDbConn(), sb);
  // row contents:
  // { "user_id": "U001", "user_nm": "Mike Davis", "income_am": "1200000", "birth_dt": "20250101" }

  // Set to response → returns to browser as JSON as-is
  io.putAll(row);
  // ↑ Key names = HTML name attributes, so they're automatically set to each screen field
}

Benefits of Unified Naming:

No conversion code needed: No need for camel case conversion (user_id → userId)
Reduced code volume: No need to write mapping logic
Reduced bugs: No conversion mistakes
Improved maintainability: Database design documents function as specifications

Type-Safe and Null-Safe Data Retrieval

You might be concerned: "Isn't it not type-safe without Beans?"

The Io class addresses this by providing type-safe and null-safe get methods.

Null Safety

In regular Maps, get() returns null, which causes NullPointerException.

// Regular Map
Map<String, String> map = new HashMap<>();
String value = map.get("key"); // null → causes NullPointerException

In the Io class, basic methods do not return null. To retrieve null, explicitly use Nullable methods.

// Io class
String value = io.getString("key");         // "" (blank instead of null)
String value = io.getStringNullable("key"); // null (explicitly retrieve null)

Type Safety

Type conversion methods are provided, and when type conversion errors occur, they log the key and value.

int age = io.getInt("age");                       // Blank converts to zero
BigDecimal income = io.getBigDecimal("income_am"); // Preserves precision
LocalDate birthDt = io.getDateNullable("birth_dt"); // Date format check

Even when type conversion errors occur, the source is always consolidated in the Io class's get methods. Since the error log outputs the key and value, when giving correction instructions to AI, "which key's value is invalid" is clear, making validation and other countermeasures easy.

Bug Prevention Features

The Io class has features that prevent bugs commonly found in regular Maps.

Strict Key Duplication Check

Detects unintended value overwrites.

// Regular Map
map.put("user_id", "U001");
map.put("user_id", "U002"); // Overwritten (no warning)

// Io class
io.put("user_id", "U001");
io.put("user_id", "U002");      // Error (logs the key)
io.putForce("user_id", "U002"); // Use intentionally when overwriting

Non-Existent Key Retrieval Error

Detects typo mistakes.

// Regular Map
map.put("user_id", "U001");
String value = map.get("userid"); // null (doesn't notice typo)

// Io class
io.put("user_id", "U001");
io.getString("userid"); // Error (logs non-existent key)

These checks provide "declared variable"-like safety while being a Map.

Deep Copy Safety

The Io class performs deep copies when storing and retrieving lists and nested maps.

// Deep copy on storage
List<String> srcList = new ArrayList<>(Arrays.asList("A", "B"));
io.putList("items", srcList);
srcList.add("C");  // Modify original list
// io.getList("items") remains ["A", "B"] (no effect)

// Deep copy on retrieval
List<String> gotList = io.getList("items");
gotList.add("D");  // Modify retrieved list
// io.getList("items") remains ["A", "B"] (no effect)

This prevents unexpected side effects from reference sharing.

Benefits

No Entity / DTO / Form classes needed: Code volume is significantly reduced
No conversion code with unified naming: HTML → Java → SQL connects seamlessly
Same approach as JavaScript: Unified key-based access from front to back
Built-in bug prevention: Null-safe, type-safe, key duplication check, existence check
Safe with deep copy: Prevents side effects from reference sharing
Easy for AI to generate code: Patterns are simple and consistent

Drawbacks

IDE code completion doesn't work: Beans offer field name completion, but Map key strings don't get completed
- However, bug prevention features (error on non-existent key) cover this
- Also, AI generates code including key names, which covers this
No compile-time type checking: Beans guarantee field types at compile time, but Maps check at runtime
- However, Io class's type conversion methods safely convert at runtime
- Supplement with validation logic beforehand

Conclusion

Some may feel uneasy hearing "no Beans."

However, by eliminating the Entity / DTO / Form Bean class layer, code volume decreases, bugs from field name mismatches disappear, and work volume when adding new screens or tables is significantly reduced.

Combined with the Io class's bug prevention features (null-safe, type-safe, key duplication check, existence check), I believe the weaknesses of Map are practically covered.

Check out the other articles too!

01 Why I Built a Java Framework
02 Direct URL-to-Class Mapping
03 JSON-Only Communication
04 Mockup = Implementation
05 Dynamic List Rendering
06 Custom HTML Attributes
07 Map-Based Design (this article)
08 Single-File CSS Design
09 Client-Side Data Management and JWT Auth
10 SQL Directly in Java
11 Why Go Vanilla?

SIcore Framework Links

All implementation code and documentation are available here:

Website: https://onepg.com
GitHub: https://github.com/sugaiketadao/sicore
How to verify sample screens (VS Code): https://github.com/sugaiketadao/sicore#%EF%B8%8F-how-to-verify-sample-screens---vs-code
Getting started with AI development: https://github.com/sugaiketadao/sicore#-getting-started-with-ai-development

Thank you for reading!
I'd appreciate it if you could give it a ❤️!

Custom HTML Attributes - Why I Built a Java Framework (third attempt in 10 years) #06

sugaiketadao — Tue, 10 Feb 2026 01:42:50 +0000

Introduction

This time, I'll cover "Custom HTML Attributes" in SIcore.

The framework's custom data-* attributes enable concise implementation of common patterns.

Basic HTML ⇔ JSON Mechanism

In SIcore, the name attribute (or data-name attribute) of HTML elements serves as the key for exchanging data with the server in JSON format.

Basic Flow

【Browser → Server】
Execute PageUtil.getValues()
    ↓
Retrieve values from HTML elements with name attributes to generate request JSON
    ↓
Send request JSON to server

【Server → Browser】
Receive response JSON from server
    ↓
Execute PageUtil.setValues(res)
    ↓
Set response JSON values to HTML elements with name/data-name attributes

During this process, custom HTML attributes (like data-check-off-value and data-value-format-type) automatically perform value conversion and formatting.

What This Article Covers

Three main custom HTML attributes
- data-name attribute (display-only elements)
- data-check-off-value attribute (checkbox OFF values)
- data-value-format-type attribute (automatic formatting)
Benefits of each

data-name Attribute: Display-Only Elements

Purpose

Used when you want to display values in elements other than form input elements (<input>, <select>, etc.).

Implementation Example

<!-- Input element (name attribute) -->
<input type="text" name="user_id">

<!-- Display-only element (data-name attribute) -->
<span data-name="user_nm"></span>
<td data-name="list.pet_nm"></td>

JavaScript Behavior

// On get: retrieve only name attributes (data-name not retrieved)
const req = PageUtil.getValues();

// On set: set values to both name and data-name
PageUtil.setValues(res);

Benefits

Values can be set in non-input elements like <span> and <td>
Can use the same naming convention as name attributes
Clearly separates display-only fields from input fields

data-check-off-value Attribute: Checkbox OFF Values

Purpose

Defines the value to include in the request when a checkbox is OFF.

Implementation Example

<!-- When checked: "1", when unchecked: "0" -->
<input type="checkbox" name="is_dog" value="1" data-check-off-value="0">

<!-- When checked: "true", when unchecked: "false" -->
<input type="checkbox" name="is_cat" value="true" data-check-off-value="false">

Request JSON

// When checked
// { "is_dog": "1", "is_cat": "true" }

// When unchecked (OFF value is automatically included)
// { "is_dog": "0", "is_cat": "false" }

Benefits

Normal <form> elements don't send values when unchecked, but this attribute includes the value
Explicitly define the OFF value for checkboxes
No need for server-side processing to supplement OFF values

Note

Do not use for non-mandatory database search conditions (since the common specification is to exclude conditions when there's no value).

data-value-format-type Attribute: Automatic Formatting

Purpose

Automatically formats values for display and automatically unformats (returns to original format) when sending requests.

Setting Values

Value	Format Type	Input Value (Example)	Display Value
`num`	Number (comma-separated)	`1000000`	`1,000,000`
`ymd`	Date (YYYY/MM/DD)	`20251231`	`2025/12/31`
`hms`	Time (HH:MI:SS)	`123456`	`12:34:56`

Implementation Example

<!-- Number (comma-separated) -->
<input type="text" name="income_am" data-value-format-type="num">

<!-- Date (YYYY/MM/DD format) -->
<input type="text" name="birth_dt" data-value-format-type="ymd">

<!-- Time (HH:MI:SS format) -->
<input type="text" name="start_tm" data-value-format-type="hms">

JavaScript Behavior

// Display response in browser: automatic formatting
PageUtil.setValues({
  income_am: "1200000",  // → Display: "1,200,000"
  birth_dt:  "19870321", // → Display: "1987/03/21"
  start_tm:  "093000"    // → Display: "09:30:00"
});

// Generate request from browser input: automatic unformatting
const req = PageUtil.getValues();
// {
//   income_am: "1200000",  // Commas removed
//   birth_dt:  "19870321", // Slashes removed
//   start_tm:  "093000"    // Colons removed
// }

Java-Side Processing

// No unformatting needed on Java side (already unformatted values arrive)
BigDecimal income = io.getBigDecimal("income_am");      // 1200000
LocalDate birthDate = io.getDateNullable("birth_dt");   // 1987-03-21

// Can be registered directly to DB
SqlUtil.insert(getDbConn(), "t_user", io);

Benefits

Automatic conversion between display format and database storage values
No need to write formatting logic in Java or JavaScript
Separates appearance from data
Server API can return database format values directly without conversion to display format

Other Custom Attributes

The following attributes are also defined for internal framework use:

Custom Attribute	Purpose	Notes
`data-style-display-backup`	`display` style value before hiding	Used when re-displaying
`data-style-visibility-backup`	`visibility` style value before hiding	Used when re-displaying
`data-title-backup`	`title` attribute value before error message	Used when clearing error display
`data-obj-row-idx`	Array data index value	Mainly used in `<table>`, set on request and used for error display on response
`data-radio-obj-name`	Original `name` attribute value of radio button	Mainly used in `<table>` for per-row grouping

These are mainly used automatically within the framework, so you don't need to be aware of them in normal implementation.

Conclusion

SIcore's custom HTML attributes enable concise implementation of common patterns.

In particular, the data-value-format-type attribute improves development efficiency by eliminating the need to write formatting logic in both Java and JavaScript.

Next time, I plan to introduce Map-type design.

Check out the other articles in this series!

01 Why I Built a Java Framework
02 Direct URL-to-Class Mapping
03 JSON-Only Communication
04 Mockup = Implementation
05 Dynamic List Rendering
06 Custom HTML Attributes (this article)
07 Map-Based Design
08 Single-File CSS Design
09 Client-Side Data Management and JWT Auth
10 SQL Directly in Java
11 Why Go Vanilla?

SIcore Framework Links

All implementation code and documentation are available here:

Website: https://onepg.com
GitHub: https://github.com/sugaiketadao/sicore
How to verify sample screens (VS Code): https://github.com/sugaiketadao/sicore#%EF%B8%8F-how-to-verify-sample-screens---vs-code
Getting started with AI development: https://github.com/sugaiketadao/sicore#-getting-started-with-ai-development

Thank you for reading!
I'd appreciate it if you could give it a ❤️!

Dynamic List Rendering - Why I Built a Java Framework (third attempt in 10 years) #05

sugaiketadao — Sat, 07 Feb 2026 13:38:17 +0000

Introduction

In the previous article, I covered SIcore's "Mockup = Implementation" concept — how static HTML mockups become implementation code.

This time, I'll explain "Dynamic List Rendering" — how SIcore automatically expands array data from the server into table rows or list elements using templates.

What This Article Covers

What dynamic list rendering is
Automatic row generation using templates
Implementation steps and code examples
Benefits

What is Dynamic List Rendering?

In SIcore, array data [{}, {}] returned from the server is automatically expanded into row elements using HTML templates.

Traditional JSP requires loop constructs like <c:forEach>, but SIcore only requires defining a template row — the array data expands automatically.

Implementation Steps and Code Examples

Step 1: Define the Template Row

Define a template row inside the <tbody> tag using <script type="text/html">.

Static HTML (template row only):

<table>
  <tbody id="list">
    <script type="text/html">
      <tr>
        <td><input name="list.pet_nm"></td>
        <td><input name="list.weight_kg"></td>
      </tr>
    </script>
  </tbody>
</table>

Key points:

Add id="list" to the <tbody> tag
Wrap the template row in <script type="text/html"> (planned migration to <template>)
Use the naming pattern list.field_name for the name attributes (where list matches the JSON key)

Step 2: Fetch Array Data from Server and Display

JavaScript:

// Generate request JSON from browser input
const req = PageUtil.getValues();
const res = await HttpUtil.callJsonService('/services/exmodule/ExampleListSearch', req);

// Response JSON
// {
//   "list": [
//     {"pet_nm": "Pochi", "weight_kg": "5.0"},
//     {"pet_nm": "Tama", "weight_kg": "2.5"}
//   ]
// }

// Auto-generate rows from response JSON
PageUtil.setValues(res);

Result: Rows Added to HTML

Result HTML (template row + generated rows):

<table>
  <tbody id="list">
    <script type="text/html">
      <tr>
        <td><input name="list.pet_nm"></td>
        <td><input name="list.weight_kg"></td>
      </tr>
    </script>
    <tr>
      <td><input name="list.pet_nm" value="Pochi"></td>
      <td><input name="list.weight_kg" value="5.0"></td>
    </tr>
    <tr>
      <td><input name="list.pet_nm" value="Tama"></td>
      <td><input name="list.weight_kg" value="2.5"></td>
    </tr>
  </tbody>
</table>

PageUtil.setValues(res) automatically expands the array data into table rows.

Explicit Row Addition

You can also explicitly add rows via JavaScript without receiving array data:

// Add a single row
PageUtil.addRow('list', {pet_nm: 'Pochi', weight_kg: '5.0'});

// Add multiple rows
PageUtil.addRow('list', [
  {pet_nm: 'Pochi', weight_kg: '5.0'},
  {pet_nm: 'Tama', weight_kg: '2.5'}
]);

Benefits

1. No Loop Construct Needed

You don't need constructs like JSP's <c:forEach> or Thymeleaf's th:each. Just define a template row, and array data expands automatically.

2. Easy Transition from HTML Mockups

Simply wrap table rows created during the mockup phase in <script type="text/html"> to turn them into implementation code.

3. Server Just Returns JSON

The server (Java) doesn't need to worry about loop processing — just return array data as JSON.

// Java code
public void doExecute(Io io) {
  // Database query
  final IoRows rows = SqlUtil.selectBulk(getDbConn(), SQL_SEL_PET);
  // Set result rows
  io.putRows("list", rows);
}

Conclusion

SIcore's dynamic list rendering feature makes displaying array data simple and concise.

Next time, I'll introduce SIcore's custom HTML attributes.

Check out the other articles in this series!

01 Why I Built a Java Framework
02 Direct URL-to-Class Mapping
03 JSON-Only Communication
04 Static Mockup = Implementation
05 Dynamic List Rendering (this article)
06 Custom HTML Attributes
07 Map-Based Design
08 Single-File CSS Design
09 Client-Side Data Management and JWT Auth
10 SQL Directly in Java
11 Why Go Vanilla?

SIcore Framework Links

All implementation code and documentation are available here:

Website: https://onepg.com
GitHub: https://github.com/sugaiketadao/sicore
How to verify sample screens (VS Code): https://github.com/sugaiketadao/sicore#%EF%B8%8F-how-to-verify-sample-screens---vs-code
Getting started with AI development: https://github.com/sugaiketadao/sicore#-getting-started-with-ai-development

Thank you for reading!
💖 If you found this helpful, I'd appreciate a like!

DEV Community: sugaiketadao

Always Pair VLOOKUP with ISNA (or IFERROR)

The Problem

Fix with ISNA

Shorter: Use IFERROR

Comparison

Bonus: Use ISNA for Conditional Display

Takeaway

About SIcore Framework

CSS Blocks and Inlines — What I Wish I'd Known on Day One

Introduction

Block vs. Inline — The Short Version

Block Elements

Inline Elements

CSS That Doesn't Work on Inline Elements

Switching Display with the display Property

Make an inline element respond to size and vertical margin → display: block

Make block elements flow side by side while keeping size control → display: inline-block

Common Traps

Trap 1: Setting width on a <span> has no effect

Trap 2: <a> tags have a tiny click area

Trap 3: Trying to place <div> elements side by side

Check It in DevTools

Quick Reference

Wrapping Up

SIcore Framework Links

Related Articles

Why Go Vanilla? — Why I Built a Java Framework (third attempt in 10 years) #11

Introduction

What "Vanilla" Means Here

Benefit: Plays Well with AI Code Generation

Unified patterns

Lower token consumption

No magic

Works for beginners too

Welcoming AI as a New Kind of Developer

Series Recap

Closing Thoughts

SIcore Framework Links

Related Articles

Four Pagination Strategies for Enterprise Database Lists

Introduction

What Pagination Needs to Get Right

Strategy 1: Per-Request DB Access — Row Number (OFFSET)

Drawbacks

Strategy 2: Per-Request DB Access — Application-Side Scrolling

Drawbacks

Strategy 3: Single DB Query — Work File Cache

Benefits

Drawbacks

Strategy 4: Single DB Query — Work Table Cache

Benefits

Drawbacks

Comparison Summary

Per-Request DB Access (Strategies 1 & 2)

Single DB Query + Cache (Strategies 3 & 4)

Which Strategy Fits Which Situation?

Wrapping Up

SIcore Framework Links

Related Articles

When Is It OK to Build a System with AI Alone? A Framework for Thinking About Responsibility

Introduction

Breaking Down "Responsibility"

Systems Where AI Alone Is Dangerous

Systems Where AI Alone Is Fine

Summary

Related Articles

SQL Directly in Java — Why I Built a Java Framework (third attempt in 10 years) #10

Introduction

What This Article Covers

The Problem with XML-Based SQL

SqlBuilder — Dynamic SQL Assembly

Basic Usage

Variable-Length IN Clauses

Key Methods

SqlConst — Static SQL Definition

Basic Usage (Declare as a Class Field)

Bind Types (BindType)

Binding at Runtime

PreparedStatement Caching with SqlConst

Switching Display with the `display` Property

Make an inline element respond to size and vertical margin → `display: block`

Make block elements flow side by side while keeping size control → `display: inline-block`

Trap 1: Setting `width` on a `<span>` has no effect

Trap 2: `<a>` tags have a tiny click area

Trap 3: Trying to place `<div>` elements side by side

What I Learned Developing a Custom Framework with Generative AI