Ted,
It isn't 'some random guy's github' (it's ok, I do get exactly where you're coming from). It's a professionally developed library that we've been developing and using in production as a commercial product for a very long time. Over the last 3-4 years we've used it alongside SAS to deliver operational information systems that support upwards of 2k concurrent users, some of which our clients say bring them over $100 mil in annual benefit. We're a SAS partner, ok only 7 people, but atypically most of our guys are experienced Java and HTML5 devs. We specialise in the exact kind of application development you're talking about, hence I hang out and try to help in this subforum.
What the adapter enables you to do is separate your front end and back end logic when building your web applications, as is standard practice everywhere outside the SAS world. It lets you hire experienced HTML5 app developers to do your front end, while you take care of the back-end application logic in SAS. Have a read the documentation available on GitHub, and maybe have a look at https://github.com/Boemska/h54s-angular-seed-app as well - personally I think this explains what the adapter does much better than the h54s page. What the codebase does is facilitate AJAX communication to SAS by wrapping the native AJAX object in a very SAS-specific way, by allowing the SAS programmer and HTML5 programmer to pass tables back and forth to build asynchronous applications. It also handles redirects to the SASLogon application, debug logs, and a couple of other things. It's open-source, so you're free to inspect what the code does - there's no black magic there.
In regard to your last question - just because these kind of solutions are currently implemented in large corporations using put statements doesn't make it right. It is done this way because until now there hasn't been a better alternative. Architecturally it's a terrible way of doing things - it's extremely bad practice, not to mention that streaming static content is a very bad use of your analytical processing CPU time. There are a couple of reasons why as a community we've evolved into doing this with put statements; the first, I think, is that the problem's mostly been approached by SAS devs from a SAS-developer-centric standpoint, learning 'just enough' HTML coding without taking the time to properly learn/understand web application architecture and follow the established best practices that the rest of the world does. The other, I'd say more obvious one, is that until SAS 9.4 we haven't had our own web server / static area (htdocs) provided by apache where we could easily host our html/js/css files - the best we've had is a static.war deployed within tomcat/jboss alongside the other SAS web applications (hosting static files from a JVM is again really bad practice, which is what static.war does). This lack of access to a proper web server to host these static files on has made it very difficult to develop web applications properly, and before 9.4 people would have to beg IT to give them some webserver space; so as you'd expect, everyone ended up using put statements to output static html content.
This doesn't change the fact that this 'established' approach is extremely hacky and bad practice. We hire experienced HTML5 application developers for this exact reason, and it's their guidance that's resulted in us developing apps the way we do. I have nothing to sell to you, nothing to gain from you using the code we made available... you don't have to use it. Nevertheless I highly recommend you build your applications in this way. What I'd say is, see if your organisation has a digital/marketing team who build webapps for a living, and then try to engage with them to help you build some of these front ends. Maybe have them to look at the codebase as to help you understand what the H54S library does - there's no way you should have to shoulder the responsibility of incorporating third party code that you don't fully understand.
I can see what you're trying to achieve, and I know this post comes over a little argumentative but I'm just trying to help. We were where you are around 4 years ago. If you want to see some of the work we've delivered for our own clients feel free to ping me. I think you'll be blown away.
Nik
... View more