go to post Sergei Sarkisian · Oct 30, 2017 Hi! You can use custom Caché Login Page as the simplest solution. Suppose, you have React (it doesn't matter anyway) csp-application as a client and you need to authenticate single user at time. You can create login.csp page somewhere in your project and set it as custom login page. Content could be like this (basic implementation, styles not included): <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Caché Login</title> </head> <body> <div id="login"> <div> <div> <form name="Login" method="post"> <div> <div> <div> <input type="text" placeholder="Login" name="CacheUserName"> </div> </div> <div> <div> <input type="password" placeholder="Password" name="CachePassword"> </div> </div> <button type="submit">Log in </button> #($select( ($Get(%request.Data("Error:ErrorCode",1))'="")&&($$$GETERRORCODE($Get(%request.Data("Error:ErrorCode",1)))'=$$$ERRORCODE($$$RequireAuthentication)): "<div>The user name or password is incorrect</div>", 1:"") )# </div> </form> </div> </div> </div> </body> </html> You can change the content of this page to match your application look and logic. You can include any 3rd-party scripts and styles. Then, in your client app settings (Management Portal) set recently created login.csp page as custom login page. Also, set Allowed Authentication Methods to "Password" and Session Cookie Path to the same value for both client and rest applications. After user will be authenticated, browser will use Cookies. You can log out from application just by redirecting user to current URL with ?CacheLogout=1 appended. You can also reload the page each %session.AppTimeout)#' + 15) * 1000 ms to automatically redirect user to login page if session is closed (don't forget to reset this counter after rest requests or/and send some sort of throttled ping after user interactions).
go to post Sergei Sarkisian · Feb 7, 2017 So, in typical AngularJS approach, you usually create views (aka states) of your app. One state — one controller. You need to define one big markup for this state which will contain all the elements of the state. And whole content of this state is controlled by its controller (hah). Which can be very complicated in big states with a lot of elements and logic. It's hard to maintain, it's hard to test and it's hard to change and refactor. In component approach introduced in Angular 1.5, you usually create components instead of states. One component — one controller. In this approach each state is component, which contains other components. <body> <app> </app> </body> Where <app> is component. And <app> itself is like <header> </header> <form> </form> <footer> </footer> Where <header>, <form> and <footer> are also components. And <form> could be like <search> <form-input> <form-input> <form-button> Where <search>, <form-input>'s and <form-button> are also components. So you will end up with a tree of components, where each component will have own logic and markup and it's rather small and isolated. Small components with isolated logic is basis of component approach. It's much easier to test, to exchange components when you need, to reuse them and to remove them. Usually, each component stores in its own directory, with separated logic, markup and styles. For instance: –app (main directory of app) ––components (directory to store all the components) –––app (directory for root app component) ––––app.component.js (app component controller) ––––app.component.html (markup) ––––app.component.css (styles) –––header (directory for header component) ––––header.component.js (controller) ––––header.component.html (markup) ––––header.component.css (styles) This approach is becoming standard now in frontend development. WebComponents itself, Angular, React, Vue are following this approach. I didn't use it with AngularJS (1), at some point I just desided to move to Angular (2). But if you try to search something like "Angular 1.5 component", you will find a lot of information about such approach in AnglularJS. For example, here is a pretty fine introduction in components in AngularJS 1.5:https://www.sitepoint.com/building-angular-1-5-components/
go to post Sergei Sarkisian · Feb 6, 2017 I can add something from myself.Let's begin with AngularJS (aka Angular 1).If you're using AngularJS, you don't really need jQuery at all. And it's absolutely different from way jQuery is usually used. You should manipulate the DOM in "Angular way", inside $digest cycle, for Angular to be aware about your DOM changes. You can call digest by yourself, but in big applications such usage will quickly lead to very poor application performance. But if you need to do something specific (for example, adapt some external component for using with angular app), there is jQuery Lite inside AngularJS, which you can use inside "link" or "compile" functions of directive (http://www.ng-newsletter.com/posts/directives.html).There are also two approaches of building apps in AngularJS:1) Initial "view-controller" approach2) New "component" approach which was created for easier migration to Angular 2.The second approach a way modular and better in terms of encapsulation and maintainability.The first approach is hard to maintain in big applications, because you will have very big scope graph which can lead to memory leaks. You will need good JS skills to prevent wrong usage of anonymous functions (especially as callbacks), circle linking, closures. You also will need a good knowledge of Angular internal design and lifecycle, to optimize such things as event bindings and watchers.The learning curve of Angular is steep. A lot of things that can be accidentally messed up, a lot of problems will come from two-way binding and digest loops.This is a very good example of how big (and good) angular application looks like:https://github.com/ProtonMail/WebClientAngular 2 (now it calls just Angular and will have major updates every half a year)You don't need to know nodejs to use Angular 2. You will need some tools to use it (for example: transpiler, testing tool, moduler bundler, moduler resolver), which actually works in nodejs environment, but they are usually pretty simple, handy and well-documented.TypeScript is not a different language, it's just a super-set of JavaScript, which has a syntax, similar to new EcmaScript 6/7/8 specifications. It also has some typing enhancements such as types support, interfaces, generics etc. (which Microsoft brought from their C# experience). It can be learned in couple of days (of course, if you know JavaScript and new ES6 features) and it will eventually transpiled to the EcmaScript 5 for cross-browser support.The first challenging thing which can probably confuse somebody is how Dependency Injection works in Angular. But after you get and research it, you will able to switch dependencies for different environments (such as Development, Testing or Production) changing only 1 line of code. For example, you can switch all the data services from HTTP-services to your own mock services to test your app with syntethic data.Angular is pretty well designed, much better than AngularJS. It's absolutely modular out-of-the-box, has no 2-way binding by default anymore and it's not so much MVC(MVVW), but as much as component framework now, similar to React stack, but all-in-one. It's much faster than AngularJS. It's also much maintainable and way easier to test.It also does not bound you to just HTML/CSS, you can write multiple views for different platforms and assemble them from one business-logic code. It supports Native components for compiling in Native apps for iOS and Android.Angular supports Shadow DOM by default (and it can emulate Shadow DOM in browsers which don't support it), which lead to incredible level of components encapsulation and re-usage.The API of Angular is locked, so it's pretty safe to use now in real projects. In the end.I am developing small and average Angular apps with Caché backend for almost two years and AngularJS still seems complicated for me. It requires a lot of design and planning for just avoid huge problems in the future.With new Angular things seem much orderly and maintainable. So, for new project I would recommend to use Angular 2 or, if you need or want to stay with AngularJS, use it with component approach implemented in latest versions.I also can recommend you to at least look on React stack (and maybe Vue.js) as it has a lot of positive feedbacks. It uses more functional way than Angular (which obviously much more OOP), it's more lightweight. But I'd like to note, that React is not all-in-one framework, it just a View library, so you will also need to pick some "Model" and "Controller" framefork(s) to build an app.Perhaps my answer may seem too confusing and unstructured. Sorry for this. If you have any questions about it, I will try to give accurate answer.
