Server Components – Generated Code and MetaData (Table) Driven

<RANT>

While looking through the server-side representation of data objects for a middleware server, I noticed something that really set me off…
When my simple components (CRUD + custom-operations) were deployed to the middleware server, the marshaling code was all generated Java code.

What struck me was the presence of a TON of generated repetitive code – and all I could think was – why didn’t they use a table??

What I was thinking – for each data value-object that needed to be marshaled to/from the server – can’t it be represented as attributes in a table (one entry for each parameter) which is then iterated by the marshaling engine. ┬áThe engine would evaluate each parameter type and size, do the appropriate marshaling, then go onto the next parameter.
The advantage of a marshaling table:

  1. One place to focus any maintenance – the engine.
    Fix a bug in the engine and all legacy components will benefit from the fix.
  2. One place to focus any performance optimizations – the engine.
    Performance fix here will benefit all components.
  3. Compact representation – the only thing which grows with the number/complexity of the components is the table itself.
  4. Both future-proofing and easier support for legacy components.
    With a version tag in the table in the component repository, a newer version of the engine with new features will have a chance to ‘drop back’ when encountering an old component.

Anyways – that design team had an architect or implementer that liked code generators.
This guy likes being table driven as much as possible.

BTW – the CORBA and COM support within the PowerBuilder runtime is all table driven with a single marshaling engine (which I wrote AGES ago).

</RANT>

Advertisements

SAP UI5 Presentation for SUP Hybrid Application – Part 1

This is the first of a series of posts for using the new SAP UI5 JavaScript controls and framework for SUP applications. This series will start with “see what you can have” to the details of coding and deploying to the SUP server.
This will be using an MBO tied to the ‘Employee’ table in the sample database (sampledb) in SUP to help retain familiarity with the other SUP samples.

Sample Application Overview:

The application has the ability to:

  • List all employees, then get the details for any employee record.
  • Find and display a single employee record (using the MBO object query ‘findByPrimaryKey’).
  • Create a new employee record.
  • Delete any employee record.
  • Update an employee record.

List & Update Employees

This uses the MBO object query “employee_findAll” to retrieve the data from the server. This then displays select details in an overview list. The user can then tap a specific employee to open a more detailed view with the option to either delete or update the record.  These screen images are snapped from my Android emulator – running the SUP 2.2 Hybrid Web Container talking to my SUP server.

The list of all employee records.
The list shows only a few details of the full record.
Initial Employee List for a typical application.
Tapping an employee record brings up
the details in read-only mode.
UI5_AndAppEmpDetail
Enter the employee update mode by tapping the Update button at the top of the screen.
The screen is then updated to be in read/write mode.
The image here has the “popover” field specific editor for the employee’s street address.
UI5_AndAppEmpUpdateStreet
Similarly, specifying the employee’s sex is more clear. UI5_AndAppEmpUpdateSex

Create an Employee

Creating an employee uses a slightly different UI approach to further show the non-traditional formats which are available in UI5. The approach here is to use the UI5 “input list”, which allows direct editing in the list control itself.

This picture shows the record with some fields filled in.

UI5_AndAppEmpCreateStart