In Umbraco bestaan drie verschillende mogelijkheden om webpaginas te renderen via zogenoemde macros. XSLT, Razor en via een ASP.NET Usercontrol (.ascx). Razor is een recente toevoeging aan Umbraco (sinds versie 4.6) en net zoals ASP.NET Usercontrols een sigaar uit de doos van Microsoft. XSLT is een publieke W3C standaard gebaseerd op (en bedoeld voor) XML.Binnen Tribal is sinds een jaar de keuze gemaakt om alleen XSLT te gebruiken. Of nauwkeuriger gezegd, er is de keuze gemaakt om geen usercontrols te gebruiken. Hier waren verschillende redenen voor.
Scheiding tussen front- en backend
Een belangrijk probleem met usercontrols is dat, om ze goed te bouwen, kennis van HTML en van C# (of VB.NET) nodig is. Er is geen echte scheiding tussen front en backend binnen usercontrols en het komt dan ook vaak voor dat backend ontwikkelaars HTML schrijven, terwijl frontend ontwikkelaars niets kunnen doen omdat ze geen kennis hebben van ASP.NET.
Uiteraard is het mogelijk om standaard componenten te maken die alleen maar configuratie nodig hebben maar dit is voor een bedrijf, dat veel kleine websites bouwt die allemaal verschillend zijn, niet rendabel. Concreet gezegd, frontenders moeten alleen met HTML bezig zijn en backenders moeten dat vooral niet zijn. XSLT vermijdt dit probleem door een strikte scheiding. Alle HTML bevindt zich in de XSLT en alle backend functionaliteit zoals databases aanroepen bevinden zich in de site code. Het enige contact tussen deze twee wordt gevormd door de aanroepen vanuit de XSLT naar backend functies.
Custom HTML
Het vorige punt doortrekkend; bij het ontwikkelen van websites komt het vaak voor dat design en HTML van een derde partij afkomen. Maar als dit niet zo is, zou de HTML onafhankelijk moeten zijn van de manier waarop het gerendered wordt. Bij het gebruik van usercontrols wordt dit al snel problematisch. De standaard componenten zoals buttons en lists bevatten vaak allerlei extra ongewenste HTML tags waar de originele HTML geen rekening mee houdt. Het is natuurlijk mogelijk om de HTML zo aan te passen dat het wel werkt maar dit is natuurlijk de omgekeerde wereld. Bovendien leidt dit vaak tot een cascade aan fouten in de HTML, waardoor elke kleine aanpassing mogelijk additionele aanpassingen nodig maakt op een andere plek. Strikt genomen is het ook mogelijk om de benodige aanpassingen door te voeren aan de usercontrol kant maar dit is net zoals in het bovenstaande geval te tijdrovend, kan vaak niet gedaan worden door frontender en is wederom niet rendabel. In XSLT kan de HTML zoals gewenst door frontenders worden aangepast.
HTTP POST
Usercontrols maken gebruik van een truc om goed te kunnen werken. Elke usercontrol legt nagenoeg exclusief beslag op de POST functionaliteit van de pagina (de bekende <form runat=”server”> tag). Er zijn situaties waar dit problemen op kan leveren. Uiteindelijk is hier meestal wel een oplossing voor te vinden maar dit is wederom meestal zeer tijdrovend.
De Microsoft Factor
De “Microsoft factor”: de duizend en een dingen die in de praktijk niet werken omdat er ergens een setting niet goed staat. Omdat iets net anders werkt als beschreven. Omdat de bedachte manier om een functionaliteit te implementeren aan het eind van de rit toch niet blijkt de werken omdat de afzonderlijk werkende delen helaas toch niet samenwerken. Dit is niet zozeer een objectief punt maar een dat stamt uit jaren ervaring en komt uiteindelijk neer op: hoe minder complex, hoe eenvoudiger.
De nieuw optie: Razor
Razor is een recente toevoeging aan Umbraco en lijkt op XSLT in de zin dat het functionaliteit zoals loops combineert met HTML, de zogenaamde inline code. Het handhaaft ook een duidelijke scheiding tussen front- en backend en de HTML is vrij te vormen. De syntax is gebaseerd op C# (of VB.NET) en maakt het hiermee vrij eenvoudig te gebruiken voor bestaande backendprogrammeurs. Op dit moment is Razor nog niet in gebruik binnen Tribal maar dit zou in de toekomst kunnen gaan veranderen aangezien de syntax van Razor vele malen overzichterlijker is dan XSLT.
5 Reacties