or "Didn't you say you would cover Persistent Objects in Part 5, Chris?"
Yes, that was the plan. This is a pretty important topic, so it get's its own Article
Up until now, we've display widget JSON that has been created by a basic loop. Clearly this isn't of much value. Now we have our stack connected together, and we can see that the data is flowing to the Welcome page, it's time to complete the stack and start feeding our service from "real" data.
Let's start with our (very basic) Persistent class for Widgets. We have 4 properties to hold Name, Description, Price and current Quantity. We would like to expose all of these on our page.
So, we could open up the object on our REST Service class and start spooling off properties into JSON objects. However, that will clutter up the Services and decouple the JSON generation from the source class. Instead, let's make a rule that all Persistent classes should have a method to represent themselves in a JSON form that we want (what an oddly specific way to end that sentence, I wonder if it will become relevant again in the future?).
So, we have decided that our Persistent classes should implement a Method toJSON, which will output a JSON representation of itself, as a %String. This is very straightforward on our very simple Widget class, we open a JSON object, and assign the object properties to the corresponding property on the JSON object (though these property names do not have to match as in %Id). After we have spooled all properties to the JSON object, we return it with our QUIT.
Now, we need to spool off our Records in our REST class. We will loop over all Widgets using &SQL in this instance, but your choice of iterator and search method is equally valid. We will loop over the %Id values, open the corresponding object, then push the output of that object's toJSON onto our widgetAry (the one we created in part 2).
After a compile, we should now be feeding our array of Widgets from our Persistent class. Let's load up our page and see what is being displayed.
We have real Widgets! The output isn't really taking advantage of the new fields we are providing like Description, Price and Quantity. Let's slot them into the appropriate places on the Card template. Since we are binding the entire widget being returned from the service, we don't have to do anything special to start using the new fields, they are just available to reference
"But what about our filtering, Chris?" I hear you ask? Surely we have to rewrite something to get the new fields to be filtered, since we didn't know about these fields when we implemented the filtering?
NOPE! Filtering will automagically work on the new fields without any extra effort. Let's prove it by searching on Description
In this lesson we:
- Implemented our Persistent Widget class
- Implemented the toJSON() method to provide a JSON representation of the object
- Adjusted our REST.Dispatch class to output a list of Widgets by calling the toJSON() of each
- Bound the new fields onto our Welcome page
In our next lesson we will:
- Break something, review the tools we can use to identify problems, then fix it
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