Skip to content

Port the first nine abap2UI5 samples, line for line - #1

Merged
oblomov-dev merged 5 commits into
mainfrom
claude/practical-archimedes-y329hi
Sep 28, 2026
Merged

oblomov-dev merged 5 commits into
mainfrom
claude/practical-archimedes-y329hi

Conversation

@oblomov-dev

Copy link
Copy Markdown
Member

Why

The abap2UI5 samples as cap2UI5 apps. The first nine are here to agree on the conventions before the other 120 follow. They are ported so that the ABAP original and the JavaScript file read alike line by line, and an abap2UI5 developer recognizes every call. cap2ui5 0.2.0 (cap2UI5/cap2UI5#88) makes that possible: the client an app receives is z2ui5_if_client by its own names, and the view builder is z2ui5_cl_ui5_view_builder, called as ABAP calls it.

)->a( n = `showNavButton` b = client->check_app_prev_stack( )
client->follow_up_action( val = z2ui5_if_client=>cs_event-set_title t_arg = VALUE #( ( title ) ) ).
.a({ n: "showNavButton", b: client.check_app_prev_stack() })
client.follow_up_action({ val: z2ui5_if_client.cs_event.set_title, t_arg: [this.title] });

What is in it

  • Nine samples in srv/apps/, one file per ABAP class under the same name:

    • 493, 494, 495 (Basics I to III)
    • 011 (editable table)
    • 167 (event arguments)
    • 161 (popup in popup)
    • 488 and 489 (return data and events to the caller)
    • 125 (tab title)

    ?app_start= is the same on both sides.

  • The same class as the original:

    • The original's @keywords, @summary and @docs, plus @origin.
    • The same attributes, and the same methods (view_display( ), on_event( ), …) in the same order.
    • The same dispatcher, and me->client = client as this.client = client.
    • The same texts. Only the page title says cap2UI5, and a text naming an ABAP construct names the JavaScript one.
    • The same view layout, down to the aligned v column.
  • README: the table of what maps to what, and the three things JavaScript does change:

    • A field is bound by its name.
    • Writes happen by assignment.
    • Every field is in the model.
  • test/samples.test.mjs: every sample over the wire. It checks that the view is well-formed XML and that the back button carries the nav-back wire. It drives each sample's events, including the navigation round trips between two apps.

  • CI: until cap2ui5 0.2.0 is on npm, CI packs the plugin from cap2UI5's main and installs that tarball. npm install cannot resolve ^0.2.0 before it is published. Once it is, a lockfile and npm ci replace this.

Tests

  • npm test: 9/9 against the plugin packed from cap2UI5 (#88's head, now main). This was also tried in a clean copy of this repository, with the exact commands the workflow runs.
  • All nine samples were driven in Chromium with OpenUI5 1.120: every page renders, every button works, and there are no console errors. The tab title is set by set_title.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XtDApnfmAncwrmW6fE4tCS


Generated by Claude Code

A first cut of moving abap2UI5/samples here, to agree on the conventions
before the other 120 apps follow: an ordinary CAP project on the published
cap2ui5 0.1.0, one file per ABAP class under srv/apps/, registered under
the same name so ?app_start= and the calls between samples stay as they are.

The eight samples cover the basics (493, 494, 495), a table (011), event
arguments (167), popups (161), navigation with a result (488 + 489) and
one front-end action (125), which goes through c.raw because the facade
has no follow_up_action( ) yet.

test/samples.test.mjs drives every sample over the wire, as cap2UI5's own
suite does: each one starts with a well-formed view, and its events,
popups and navigation round trips do what the sample says.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XtDApnfmAncwrmW6fE4tCS
The views are now built call for call as the ABAP originals build them,
with ViewBuilder - abap2UI5's own view builder - and the apps keep the
originals' dispatcher and methods. That makes a port a line-by-line
translation, and its view the same tree as the original's.

The facade gaps the first cut worked around are closed in cap2UI5 (branch
claude/practical-archimedes-y329hi, the next release 0.2.0), so the ports
use them instead:

- the back button is c.eventNavBack( ), no BACK branch in every main( )
- 125 sets the tab title with c.followUpAction( ), not through c.raw
- 011 binds its table with the bare path, as the original does
- 488/489 hand the result back with navBack( { event, data } ) and read
  it as c.eventData - r_data, as in the original - and bind the structure
  components by name, c.bind( "s_result.product" )
- helpers are methods again: cap2UI5 binds them to what main( ) sees

cap2ui5 0.2.0 is not on npm yet, so package.json names it and the lockfile
goes until it is; the README says how to install the plugin from a
checkout meanwhile.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XtDApnfmAncwrmW6fE4tCS
A plain npm install answers ETARGET for cap2ui5@^0.2.0 until the release;
installing the packed plugin brings the other dependencies along, measured
on a fresh clone.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XtDApnfmAncwrmW6fE4tCS
…ABAP names

cap2ui5 now hands main( ) abap2UI5's z2ui5_if_client under its own names
and exports z2ui5_cl_ui5_view_builder called the way ABAP calls it. So the
ports no longer translate - they are the originals, spelled the JavaScript
way: `client->check_app_prev_stack( )` is `client.check_app_prev_stack()`,
`->a( n = `title` v = … )` is `.a({ n: "title", v: … })`, and
`me->client = client` is `this.client = client`, with the helpers under
their ABAP names (view_display( ), on_event( ), log_step( ), …) in the
original's order.

Each file keeps the original's header (@Keywords, @summary, @docs), its
dispatcher, its texts - only the page title says cap2UI5, and a text that
names an ABAP construct names the JavaScript one - and its layout, down to
the aligned v column. 488 clears its result with `this.s_result = {}` as
the original does with VALUE #( ), which needs the structure fix in the
cap2ui5 branch.

The README's translation table shrinks to what JavaScript actually
changes: a field bound by its name, writes by assignment, and every field
in the model.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XtDApnfmAncwrmW6fE4tCS
CI ran `npm install`, which cannot resolve cap2ui5 ^0.2.0 before 0.2.0 is
published, so every run would have ended in ETARGET before a single
sample ran. It now checks out cap2UI5, packs its plugin as `npm publish`
packs it, and installs that tarball alone - the recipe the README gives
for a local checkout, tried in a clean copy of this repository: 95
packages, the nine samples green.

Once 0.2.0 is published this goes, and a package-lock.json with
`cache: npm` and npm ci come back.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XtDApnfmAncwrmW6fE4tCS
@oblomov-dev
oblomov-dev merged commit 9d7a4f7 into main Sep 28, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants