A case for a simpler, easier-to-maintain UI
But what is an XSLT? It stands for Extensible Stylesheet Language Transformations. And it is a programming language that eats XML and spits out basically whatever you want. It can be more XML, SQL, Javascript, or HTML, which is what we're going to cover. Keep in mind, this is a server-side rendering technique, so if you are using a client-side rendering technique (best practice for large userbase), then this won't help you. But if you have need to render server-side, this could be a way to do it, and still use a single-page-application.
The XSLT-UI framework is super-lightweight (code-wise), and doesn't require any dependencies (at least for .NET).
Take the XML returned from, say, your SQL Server:
<RenderedControls>
<UserList>
<User Type="Admin">Alex</User>
<User Type="SuperUser">Van</User>
<User Type="FreeUser">Roger</User>
<User>George</User>
</UserList>
</RenderedControls>
Which gets consumed by the XSLT code on the server:
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:foo="http://www.foo.org/" xmlns:bar="http://www.bar.org">
<xsl:template match ="RenderedControls/UserList" mode="ui">
<HtmlData Placeholder="GenericPopup">
<script>$("#divGenericPopup").show();</script>
<table>
<xsl:for-each select="User">
<tr>
<xsl:attribute name="name">
<xsl:value-of select="./text"/>
</xsl:attribute>
<td>
<xsl:value-of select="./text()"/>
</td>
<td>
<xsl:value-of select="@Type"/>
</td>
</tr>
</xsl:for-each>
</table>
</HtmlData>
</xsl:template>
</xsl:stylesheet>
Then, on your index.aspx (or php, or cshtml, or whatever),
You have:
<div class="middle-of-screen popup hidden" id="divGenericPopup" placeholder="GenericPopup"></div>
And after some generic code that puts the resulting HTML in its place (Javascript on the client):
<div class="middle-of-screen popup hidden" id="divGenericPopup" placeholder="GenericPopup">
<script>$("#divGenericPopup").show();</script>
<table>
<tr name="">
<td>Alex</td>
<td>Admin</td>
</tr>
<tr name="">
<td>Van</td>
<td>SuperUser</td>
</tr>
<tr name="">
<td>Roger</td>
<td>FreeUser</td>
</tr>
<tr name="">
<td>George</td>
<td/>
</tr>
</table>
</div>
You have a complete UI rendered and ready to go.
Notice thexsl:for-each in the xslt code. I'm sure you're used to doing for-each clauses in your cshtml and other rendering engines. And you can increase complexity easily.
But Why?
You might be asking: Why should I bother doing this? Well, there are several benefits to using this system.
First, XSLT is a very well-defined language based in XML with very little room for error (like HTML in a way). You have helper functions that do a little bit of work for you. You can put business logic in the XSLT, but that is not recommended.
It's better to do this on the database side in Stored Procedures (don't knock it till you try it). Because of this, you normally don't have to worry about debugging the XSLT (which you can still do in Visual Studio) because it is usually error-free. What you see is what you get. Something you normally can't say about JavaScript rendering frameworks.
Second, XSLT is a Turing-Complete language. It still allows functional programming through <xsl:call-template> which will apply a template you have specified as a helper template (a template without the match attribute) onto the XML selection you pass to it. Using this framework, you can accomplish all tasks you would ever need to with XML.
Tools
You can try using Visual Studio, but that's really only best for updating an existing XSLT. For creating a new one with a good framework, I recommend Oxygen. Visual Studio does have intellisense support for XSLT, so you can feel safe using that too.
You can also use Visual Studio to debug an XSLT, stepping through the code and watching the resulting HTML being generated.
Great, where do I start?
You can develop your app how you normally would, one feature/module at a time. You can use different Xslt's by importing them into one "Master" XSLT: <xsl:import href="RegenerateUI.xslt"/> which basically inserts the code at runtime.
Start by creating the canvas UI with placeholders described above for each section of your UI. Use Javascript to call your server code, knowing that either an error, or HTML will be returned, preparing to insert it where instructed.
Setup your server code to receive parameters from Javascript and call your database. The returned XML from the database should be fed into the master XSLT, and the HTML, along with any "placeholder-to-use" values should be returned to the client and displayed.
Ho! Ho! Ho! Merry Christmas!! I've given you an upvote and left you this amazing automated comment!!
Congratulations @alavan! You have completed the following achievement on the Steem blockchain and have been rewarded with new badge(s) :
Click here to view your Board of Honor
If you no longer want to receive notifications, reply to this comment with the word
STOPTo support your work, I also upvoted your post!