ASP.NET Core MVC

Observations about ASP.NET MVC Core and converting YetaWF from ASP.NET MVC5 to ASP.NET Core MVC. The new MVC6 has great new features. Getting there from an existing MVC 5 app is HARD!

100% SPA, 100% ROCA, Well Almost

11/08/2018

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.

I ran across ROCA (https://roca-style.org/index.html) and said, hey they copied my ideas... Well, of course they didn't. Apparently I'm not the only one that sees some flaws in today's client-side JavaScript frameworks. Don't get me wrong, I have worked with my share of client-side applications, but there are some obstacles and pitfalls. ROCA just spells them out.

So here is the scorecard for YetaWF, how well it follows ROCA principles.

Server-Side

#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).

Client-Side

#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.
#UNOBTRUSIVE-JAVASCRIPT   In line with the principles of progressive enhancement, JavaScript is used unobtrusively and the application remains usable (albeit with a decrease in usability and convenience) if JavaScript is disabled.
This doesn't really seem all that relevant as YetaWF supports modern browsers. JavaScript disabled? LOL. No score given for that reason.
#NO-DUPLICATION 100% The same functionality must not be implemented redundantly on both the client (JavaScript) and the server. Thus, due to the application logic requirement, application logic must not reside on the client-side.
#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.
#STATIC-ASSETS 99.4% All JavaScript code and CSS code must be static, and must not be dynamically generated by the server in a form specific to the resource requested. (Note that this does not prohibit the use of preprocessors like CoffeeScript or LESS, as the respective code is usually pre-compiled as part of the release process.)
YetaWF generates small snippets of "glue" code, usually just to initialize specific elements.
#HISTORYAPI 100% Any dynamic routing or URI state modification triggered by JavaScript on the client side should use the HTML5 History API.

No Comments

Be the first to add a comment!

Add New Comment

Complete this simple form to add a comment to this blog entry.