Let's write an Angular 1.x app with a Caché REST backend - Part 12

In our last lesson, we added some formatting and validation to our Edit Widget form.  So, now we are ready to add the ability to add new Widgets to our application.  However, the great Widget Wars have come to an abrupt end, as Widget Direct has purchased its biggest competitor, WorldWideWidgets.  In order to maintain some continuity, we need to display their catalog on our new application.

So, we have good news and bad news.  The good news is at that WorldWideWidgets also use Caché, but the bad news is that their Widget table has different properties with different names than our Widget class, and we need to keep the catalogs seperate for the time being.  WorldWideWidgets don't have a WidgetAccessory catalog (and they wonder why they lost the Widget War), so we don't need to worry about Accessories for now

So, this is a serious problem, it looks like we need to implement 2 sets of pages, components and services.  Or do we?  Since the JSON representation is not tightly linked to the persistent class, we can actually export these Widgets with the property names of the original Widget class, which will then allow us to display and update them using our existing components and controllers.

So first, we implement the toJSON on the WWWidget class.  We map the property names to the existing names, implement the additional properties with their actual names, and to differentiate these Widgets from our original catalog, we will prepend the ID value with a 'W'

and then we will alter our REST.Widget class to return all WWWidgets in addition to our Widgets.  We will implement a second cursor, and push the toJSON representations of these widgets onto our widget array.

We can check our REST Service to check that the Widgets from both classes are being returned.

Now that we have our GET working, we can work on allowing Update of our new class.  This is  a reverse of the toJSON, where we will iterate over all properties we received, and manually map them to the actual properties of the class of WWWidgets.

We now need to make sure our PUT service is able to choose between our 2 Widget classes.  Luckily, we prepended the ID of the WWWidget class with a W, so we have an easy way to differentiate between each class.  If the first character of the ID is a 'W' then we %OpenId with the rest of the ID value.

So, to prove that our updates are now working, we can use our Welcome.csp page.  Let's open up W3, and update the price, and check that everything updates correctly

Success!  We can now update Widgets in both tables seamlessly.  We can implement a similar condition on our GetWidgetById method to load instances of either class, based on the W prefix of the ID.  

We should also implement a method to add new WWWidgets next?  Well, since we are winding down that catalog, then we will not implement any methods to add new entries.  We now have full WWWidget support as part of our application

Today we:

1. Imported another Widget class
2. Implement toJSON and fromJSON methods
3. Implement logic to return and set WWWidget entries

Next time we will:

• implement an "Add New" form for Widgets

This article is part of a multi-part series on using Angular on top of Caché REST services.  The listing of the full series can be found at the Start Here page