Comment by scotty79
3 months ago
Sorry, I misspoke. What I had was that contents of the page were served to the browser as XML. The browser automatically requested the appropriate XSLT to convert the XML to XHTML to display it nicely. Basically same thing that you had, except that I didn't need feeds.
What I wanted to say is that I didn't write XSLT by hand. Instead I was writing XHTML files with just few short, convenient markers, and my regexps based "compiler" converted them to various xls nasty tags generating output XSLT that was served.
For example `$name` was converted to `<xsl:value-of select="name" />` and `@R:person` was converted to `<xsl:for-each select="person">` and `@E` was converted to `</xsl:for-each>`
Basically there were 5 tags that were roughly equivalent to
with, for, else, if, end
`with` descended into a child in XML tree if the child was present and displayed enclosed XHTML
`for` displayed copy of the enclosed XHTML for each copy of its argument present in XML, descending into them
`else` displayed enclosed XHTML only if the argument node didn't exist in XML
`if` displayed enclosed XHTML Argument only if the element existed
Neither if nor else descended into the argument node in XML. With and for descended. XSLT was using relative paths everywhere.
`end` marked the end of each respective block.
> That would've meant the underlying XML would need to mix view and model considerations, which is exactly what we didn't want.
The thing is, what you are serving to the browser is always a View-Model. If you serve a Model instead you are just "silently casting" it onto a View-Model because at that moment they are identical. Sooner or later the need will arise to imbue this with some presentation specific information attached on the fly to data from your data layer Model.
I no longer try to use XSLT either, but I think web components are completely orthogonal tool. Your XSLT could still generate web components if you like. You could even "hydrate" generated HTML with React for interactivity.
What XML+XSLT was solving was basically skipped entirely by programmers. Instead of taking care about separating concerns, performance, flexibility they just thrown into the browser a server side generated soup that is only one step away from compiled binary and called it a day.
> The thing is, what you are serving to the browser is always a View-Model. If you serve a Model instead you are just "silently casting" it onto a View-Model because at that moment they are identical. Sooner or later the need will arise to imbue this with some presentation specific information attached on the fly to data from your data layer Model.
There's a huge difference in the level of presentation specific logic you include, though. E.g. between including the publication date of something vs. including the publication date in 4 different ways because it needs to be presented in 4 different ways in different formats and templates. One is about having to ensure a superset of the information required is available, and that superset can often involve very limited overhead (and can even end up being "cheaper" through being able to have fewer, more heavily accessed, cached items), while the other means you need to closely couple it to specific details of the presentation.
> I no longer try to use XSLT either, but I think web components are completely orthogonal tool. Your XSLT could still generate web components if you like. You could even "hydrate" generated HTML with React for interactivity.
Web components alone maybe, but combined with a higher level framework that also lets you do server side rendering, we're back to being able to serve up a single format and choose to transform it either on the server side or client side as needed, without the pain of XSL
> Your XSLT could still generate web components if you like.
Yes, but I wouldn't gain anything at all from that other than the pain of dealing with XSLT.
> What XML+XSLT was solving was basically skipped entirely by programmers.
Because XML+XSLT wasn't solving it in a way that was good enough even for people like me who badly wanted to like it. We got it to work, but neve