One source of truth for what a tag means
One source of truth for what a tag means
Phew. I've wanted this for so long: Eclipse/the template editor and the WO runtime now share a single, declarative tag registry — so the editor and the application will interpret tags through a single mechanism.
Until now, the template editor carried its own built-in "tag shortcut" registry for tags like and really had no idea whether it matched what WO would actually render at runtime. It usually did — but “usually” is where subtle, maddening mismatches live. The classic example: WebObjects frameworks *substitute* elements at runtime. Bind a and ERExtensions quietly swaps in its own ERXWOString when the page renders. That substitution lived only in framework code that ran at startup — completely invisible to the editor.
Now element tags are declared by frameworks and applications. A framework or application drops a simple parsley-tag-aliases.properties file on its classpath:
A tag shortcut and an element replacement are pretty much the same thing — an alias from one name to another — so they share one mechanism. Resolution is recursive: str → WOString → ERXWOString, following the chain to whatever your app really renders. The Parsley runtime reads this file to build pages; the editor reads the very same files from your project’s classpath.
What you get, across the whole editor:
-
Autocomplete offers the tags your project actually defines.
-
Hover and binding completion resolve the full chain. Hovering `` shows
str → WOString → ERXWOString— the truth of what renders. -
The Element Reference marks overridden elements in orange and a dedicated “Overridden by” column, so you can see at a glance which built-in elements are replaced in your project, and with what.
It is opt-in and per-project: a project that contains no alias files behaves exactly as before. And it’s the first step and foundation for something larger — a proper tag library, where a framework fully describes its own tags to the tooling.
From the changelog, June 26, 2026.