# #15 Where the Selection Screen Went Long before anyone said "full-stack" in a job ad, ABAP had this: ```abap REPORT zre_app_input. PARAMETERS pa_arbgb TYPE t100-arbgb DEFAULT `MDG_TR`. START-OF-SELECTION. MESSAGE |Input: { pa_arbgb }| TYPE `I`. ``` Four lines, and every layer is present. A screen exists. It has a labeled, typed input field with a default and value help. It validates. It handles the event. Nobody wrote a frontend, because declaring the variable *was* writing the frontend. Take a moment with that. A generation of developers built a decade of business software on it, and most of them never once thought of it as remarkable. That trade — you name the data, the system draws the screen — is what made ABAP productive for thirty years, and it is what quietly disappeared on the way to the browser. The variable and the field it appears in became two artifacts in two places, maintained by two people, kept in step by a service in between. abap2UI5 puts them back together with `_bind`:  *PARAMETERS: one declaration is the variable and the field. OData: variable and field are two artifacts with a service between. _bind: the field is the variable again.* ```abap )->tag( `Input` )->a( n = `value` v = client->_bind( pa_arbgb ) ``` The attribute is not a field name in a string. It is the ABAP variable, handed over by reference; the framework builds the model around it, ships it, takes the user's input back and puts it where it came from. What the developer maintains is a variable, in a class, next to the code that reads it. It is not the same deal as `PARAMETERS`, and pretending otherwise would be dishonest — the layout is written by hand here, because the screen is UI5 and UI5 has a great deal more to say than a selection screen did. What comes back is the other half: one place where the data lives, and no service between the field and the variable. The selection screen's best idea was never the screen. It was that the variable and the field were the same declaration.