Basically the user should be able to scan a delivery using a Dynpro Input mask. Then an ALV Grid would Show all the LIPS Positions and he could scan Materials by EAN to confirm that the quality of the position is ok.
Basically that is what i came up with:
Since I do not program Module Pools every day one tricky part was to have a clean data Model of the delivery we just work with. You can see that there are manipulating Inputs in the Dynpro as well as in the ALV toolbar, which can be used.
The manipulation of ALV Data is very well protected and always problematic. Also I consider using globals problematic whenever a program manipulates more than one data item(e.g. the delivery), since there will be problems with clean reloads of the next item.
I was not able to split the Controller from the view for the ALV composes both in our framework, but I wanted to have a common data model for both the module pool and the ALV Grid. So in he end I came up with this:
Its kind of
M(V&C). All the Data Manipulation is done by Methods of the Model
Class itself to minimize manipulation overwriting. The Model will lock itself once all QS Positions are confirmed, and needs an explicit reset to be opened again.
The only problem is, that
the ALV is embedded in the Dynpro. So whenever controls of the ALV are clicked,
I can manipulate the Data Model cleanly (by reference). Afterwards I need to
render the ALV again. Simple refresh Grid is not enough, since the ALV is inside
an Container. So I need to get into the PBO of the report, which I only managed
by calling CALL METHOD CL_GUI_CFW=>SET_NEW_OK_CODE
(any better solutions
are welcome as comments J ) ALV should refresh itself if you use it right, not like i did it at the start.
