This list of examples is going to grow over time. We are open to requests, as well as submissions if you have something you would like to share.
In this example, we use a plain old Moxie.Build system and compare it to the MEAN Stack equivalent by building two functionally equivalent versions of a fleshed out To Do List Application. Both versions utilize local user authentication, a relational database system and the security measures found in typical production-level applications on the web today.
For small and simple procedures that are not expected to grow in complexity over time, simple routing based on URL parameter values from a [Pull] directly from the Request query is sufficient and requires less code. For complex procedures that are expected to grow and evolve over time, a larger more robust foundation for the routing should be used.
In this example, you will see how to use a public method that works on or with the current WorkQuery that you pass in to the method.
Please note, this first method is meant to work ON the WorkQuery passed in which means any fields or records modified will be reflected in the output of this public method. The second method is meant to work WITH the WorkQuery provided to the method.
The purpose or use case of these public methods is when you have similar bunched logic in multiple places in your application, you may want to clean this up and abstract some of the logic out which not only improves the readability of your procedure but provides a more modular approach more inline with modern application building as well as reusability. Different use cases will be present for both of the methods provided. As the best practices of Moxie develop, this page will be updated to reflect the best design pattern for creating and consuming public methods.