Switch components bypass tag-alias resolution (runtime dynamicElementWithName)

[hugithordarson]

Low priority — flagging a known boundary of the declarative tag-alias / element-substitution mechanism.

The gap

Parsley applies tag aliases and element replacements (e.g. WOString → ERXWOString, from parsley-tag-aliases.properties) at parse time, in ParsleyTemplateParser.toElement() → ParsleyTagRegistry.resolve(), before ParsleyDefaultElementFactory.dynamicElementWithName() runs.

Switch components resolve their target element by a name that only exists at request time (from a binding), calling WOApplication.application().dynamicElementWithName(name, …) directly:

• com.webobjects.appserver._private.WOSwitchComponent._realComponentWithName
• er.extensions.components.ERXWOSwitchComponent._realComponentWithName
• er.extensions.components.ERXSwitchComponent / ERXSwitchEmbeddedPage (full Wonder)

That runtime name never passes through Parsley's resolver, so a <wo:switch>-style element targeting, say, WOString would instantiate plain WOString, not its ERXWOString replacement.

Why it's low priority

WOSwitchComponent is overwhelmingly used to switch between components, not built-in dynamic elements. In ~99% of cases, tag shortcuts and class substitution target dynamic elements — which go through the parse-time path and are fully covered. So the bypass is real but rarely, if ever, hit in practice.

Possible direction

Make the switch elements run the resolved name through Parsley's resolver before dynamicElementWithName. Since the relevant switch in a Parsley/wonder-slim app is ERXWOSwitchComponent (WO's own WOSwitchComponent is itself replaced by it), this is fixable on our side — no need to touch WO core. One clean solution is simply to route ERXWOSwitchComponent's runtime resolution through ParsleyTagRegistry.resolve(...).

Confirmed non-issues (for the record)

• WO's stock parser path (WOHTMLWebObjectTag._elementWithClass) also calls dynamicElementWithName directly, but it is parser-local: it only runs inside WOBundleComponentTemplateParser (the WOHTMLTemplateParser impl), which Parsley replaces via setWOHTMLTemplateParserClassName("parsley.ParsleyTemplateParser"). In a Parsley app it never runs.
• WOML / WOOgnl parsers: same — displaced by Parsley as the registered parser.

(Surfaced during a cross-framework audit of dynamicElementWithName callers.)