a.k.a..  "The World of Widgets Returns!" or "Paternity leave damages Instructional Series momentum"

In our last lesson, we combined 2 separate classes to appear as the same property.  We now have the ability to Update our Widget catalog, but what if we want to Create a Widget?  Thankfully, we've already done 90% of what we need, just by implementing Edits

As we mentioned when creating the REST Services for PUT and POST, the only real difference between creating and updating a record is whether we are passing in an existing ID or creating a %New record.  The actual content of the Widget JSON is exactly the same, so this allows us to be a little lazy and reuse the form and controller code we have previously written, with just some minor edits to allow it to work for New Widget

0   0 1
0

comments

334

views

0

rating

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 no

+ 2   0 2
0

comments

307

views

+ 2

rating

In our last lesson, we added a form to Edit our existing Widgets, and save them back to the server.  However, our Form was not well structured and our Save button had no intelligence, and was not fully visible.  So today, we will apply some Material components and Angular style to make the form more useful

Let's open EditWidget.csp, and make some changes.  First, we want to change the component from an md-card to an md-dialog.  We then want to wrap the content in a div so we can set the layout to "column" so the controls display in a vertical list, and also a Form which enables Angular to verify the state of the form

+ 2   0 4
0

comments

308

views

+ 2

rating

In our last lesson, we implemented a new REST Service to allow us to perform CRU operations on Widgets, and refactored our Controllers to allow the page setup to be decouple from the content.

When we created our Widget Services, we did not implement a Deletion operation, which the HTTP Delete verb provides.  As this is a base table for other parts of the Widgets Direct empire, we don't want to be able to do a hard Delete of the WIdget values, as this could cause issues with our ordering and billing modules.  So, we will add a "Deleted" property to the class, and have the Delete operation set this Boolean flag instead.  We will adjust our GetAllWidgets method to ignore any records which are marked as "Deleted"

REST.Widget

Last comment 2 March 2018
+ 3   0 6
514

views

+ 3

rating

or "Bonus Breakage"

In our last lesson, we added a relationship between 2 persistent classes.  We are clearly going to need to start creating REST Services to expose CRUD operations for each of these classes, but before we do that, we should really finish defining our linkages.  We added code to our Widget toJSON to spool off related Accessory data, so we should really do the reciprocal and allow Accessories to return all Widgets that are compatible.

The code we can use is essentially the same as we used on the Widget side.  We will iterate over the bridging class and return the toJSON of all referenced widgets.  We are definitely sure we have a toJSON for the Widget class, so we shouldn't be expecting any errors.  We add the code to WidgetAccessory and compile, before loading our service in the REST debugger to make sure everything is spooling OK

Last comment 24 September 2018
+ 3   1 2
466

views

+ 3

rating

or "Things are going to break"

We left our application over the weekend, secure in the knowledge that it was returning data from our primary persistent class, User.Widget.  However, Widgets Direct are the premier supplier of both Widgets AND Widget Accessories, so we should really start working on adding these Accessories to our application. 

We should do some housekeeping first though.  Our Page Controlller code is currently sitting in the widgetmaster.js file.  As we start to build up our application and use multiple controllers, this will make the PageController hard to find, so we should refactor it into a sensible location and file name.  So let's create modules/page/PageController.js under our web application, and paste the code in there.  We can then remove the controller code from widgetmaster.j

Last comment 5 June 2017
+ 2   0 0
578

views

+ 2

rating

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.

Last comment 4 July 2018
+ 2   0 3
715

views

+ 2

rating

At the end of our last lesson, we ended with our page displaying a nice (but garish) Angular Material Toolbar, and our Widget data displaying in a list of Material cards.  Our page feels a bit static, and we already know that the large number of Widgets that we will be dealing with will not be especially usable on a static list.  What can we do to help?


A filtering function would be very helpful, so let's add a text input to the top of the page. We will bind this to a variable in the $scope - widgetFilterText so that Angular has access to the value we type in. We will also wrap the whole page content in a div and set layout="column" to have the new text input and the existing cards arrange vertically on the screen

+ 3   0 0
0

comments

506

views

+ 3

rating

So, one day you're working away at WidgetsDirect, the leading supplier of widget and widget accessories, when your boss asks you to develop the new customer facing portal to allow the client base to access the next generation of Widgets..... and he wants you to use Angular 1.x to read into the department's Caché server.   

There's only one problem:  You've never used Angular, and don't know how to make it talk to Caché.

This guide is going to walk through the process of setting up a full Angular stack which communicates with a Caché backend using JSON over REST.  


This is a parent page for the multipart series on creating a Material-Angular1x-REST-JSON-Caché application.  The current list of articles is

Last comment 13 December 2018
+ 16   3 10
3172

views

+ 16

rating