I mentioned before, that YetaWF is by default a Single Page Application here. Sometimes I ignore academia or the latest technical theories. Instead I focus on what what I need to get done. That's how YetaWF was created, because I needed something to run company sites. Over the years it has evolved from simple framework to a full blown SPA, ASP.NET Core MVC framework, with super-fast custom development in mind.
So here is the scorecard for YetaWF, how well it follows ROCA principles.
|#REST ||100% ||The server application adheres to REST principles, i.e. it exposes a set of resources that are meaningful to a user sitting in front of a browser, each resource has its own URI, all of the information necessary for handling a request is contained within the request itself, HTTP methods are used in line with their definition, and the resource state is maintained by the server (stateless communication). |
|#APPLICATION-LOGIC ||100% ||All application logic resides on the server. |
|#HTTP ||100% ||The client interacts with the server through RESTful HTTP requests. |
|#LINK ||100% ||A user must be able to link to a specific piece of information, e.g. by copying the address from the browser's address bar and pasting it into an e-mail, creating a bookmark, or using any of the fancier ways to share URIs. |
|#NON-BROWSER ||100% ||It must be possible to use the server's logic through user agents other than a browser, e.g. a command-line client such as curl or wget. |
|#SHOULD-FORMATS ||100% ||Resources have additional representations in other formats, e.g. JSON and/or XML. |
While this is how YetaWF implements SPAs, the representations are not externally available (other than to implement an SPA).
|#AUTH ||100% ||All authenticated communication relies on HTTP Basic or Digest Authentication, typically combined with SSL, possibly with client certificates. Alternatively, because of the limits of browser-native authentication (e.g. no logout, no styling), form-based authentication in conjunction with cookies can be used. If cookies are used, they should include all of the state needed for the server to process them, and another authentication mechanism should be supported for non-browser access. |
|#COOKIES ||100% ||Cookies may not be used for purposes other than authentication, user tracking or security purposes like CSRF protection. |
|#SESSION ||90% ||There may not be any session state beyond what’s needed for simple algorithmic validation of authentication information. |
Well, a small bit of session state is used to bootstrap user (anonymous or logged on) settings.
|#BROWSER-CONTROLS ||100% ||The browser controls like the back, forward and refresh buttons must work as expected. I.e. the back button should take the users where they expect to be taken to (the last meaningful resource they worked with). A browser refresh should not cause a re-rendering of the login or home page instead of the page the user was looking at, or a (to the user) unexpected question about wanting to submit the same data again (when the user doesn't recall submitting any data, indicating a mis-use of the POST verb). |
|#POSH ||100% ||The server returns structured semantic HTML markup that is independent of layout information and client behavior. |
|#ACCESSIBILITY ||95% ||It must be possible to access each page's information and functionality by using accessibility tools like screen readers. |
Believed to be mostly accurate, however little testing has gone into this, so can't give it 100%.
|#IDIOMATIC-CSS || ||CSS is used for formatting and layout. This is done following the principles of progressive enhancement, e.g. to allow a browser not capable of CSS3 features still to use a CSS3-based site. |
This doesn't really seem all that relevant as YetaWF supports modern browsers. No score given for that reason.
|#KNOW-STRUCTURE ||100% ||The server code may not "know" the HTML structures the client code generates (beyond CSS) or vice versa. Exceptions are some well defined HTML structures the server generates to initialize the client functionality above. |
Edit 1/22/2019: In YetaWF, the client doesn't really know the HTML structures as all HTML is generated server-side (in bits and pieces). The client code only deals with individual components at a time and there is no overall client code that controls the page. The client code is driven by data tables generated server side. Some client side code (for views and complex components) is aware of field names and types (but not the HTML structure).
This is a complete deviation of original intent of #KNOW-STRUCTURE, as ROCA assumes the client-side code is in control. But still scored at 100% because the client code does not generate HTML.
YetaWF generates small snippets of "glue" code, usually just to initialize specific elements.