• (cs)

    Posting comments before the article goes live!? Wha!? How?!

    Really, the only benefit of following @thedailywtf.

  • jc (unregistered)

    Always knew such a thing would be theoretically possible but never found people crazy enough to actually do it. Kudos for this wonderful find :D

  • (cs)

    That is.... I am going to have nightmares now.

    Posting before the article goes live? Don't have to follow, can just read the sidebar :P

  • AB (unregistered)

    This is sketchy at best

  • Jack (unregistered)

    Another fine example of "just because we can do it, doesn't mean it's a good idea".

    In the Good Old Days (TM) software development was based on disciplines having to do with software and, um, development. Then came the web and the #1 attribute that mattered to anyone was "cool". This looks to me like the culmination of 20 years of trying to out-cool the other guy with yet more obscure and useless ways of doing something that ought to be simple.

    Srsly, Netscape 1 provided almost everything we needed. Inline images... well we could argue about that; sure they have their place but they also enabled banner ads... but after that, mostly just "cool" crap.

  • norsetto (unregistered)

    Fantastic, I even learned a new word today!

  • Xenious (unregistered)

    sixth!

    captcha: Penis.

  • Pony (unregistered) in reply to Xenious

    Not sixth, seventh, dude.

  • Xenious (unregistered) in reply to Pony
    Pony:
    Not sixth, seventh, dude.

    Fuck you. It is zero based. Get back on you vb script, looser.

  • oppeto (unregistered)

    Well, a reason such design never took off is that it only works on Firefox. IE doesn't support XSL transforming*

    Which is the reason why www.skechers.com provides XHTML (with a HTML4 strict doctype) if you use a IE user-agent (just 'MSIE' as user-agent works).

    So the server needs to be able to do the template transformation itself anyway. At that point, it doesn't make sense to show something different to other browsers... unless you are skechers. (and yes, the default is XML, not the other way round)

    • As for Opera, Safari... I haven't tried.
  • David Kotsonis (unregistered)

    I'm reasonably certain that this constitutes grounds for a boycott.

  • Lester (unregistered)

    Ha, and with NoScript in place, the XSL works but yields some JavaScript which doesn't run, yet NoScript doesn't realize it, so you can't enable it, so... you're stuck. Ridiculously complex for absolutely no good reason.

  • Anon (unregistered)

    Im fairly sure that the world of Warcraft armory does something similar?

  • Anon (unregistered)

    My mistake, perhaps it was an older version but i distinctly remember being told it did this.

  • (cs)

    Ahhhh! My eyes! The goggles, they do nothing!!!

  • David (unregistered)

    Actually I think this is a legit design - if the enterprisey ERP system spits out the XML and you want to throw it straight at the web, then all's you need is to insert the stylesheet markup and write the xslt. No Real Programming Required (tm). The xslt is basically doing what you'd be writing in C# or PHP or whatever anyway - read xml, write html. Makes sense to me to skip the middleman, otherwise what do we have xsl for?

    Of course if they've written code that takes stuff from the ERP system and generates the XML, then that's another story altogether...

  • (cs)

    XSLT as a programming language: TRWTF.

    I mean: while the ideas behind XSLT and XPath are quite neat, I don't quite get why anybody thought it would be a great idea to express them in XML. I guess someone was having grand ideas about XSLT meta-processing XSLT or something, but now look what happened...

  • (cs)

    I have used client-side XSL before to translate source XML I was given into various formats. Never again. I wanted to support multiple browsers but each one translates XSL a little bit differently, and of course each one has different rules for validating XML DTDs.

    Oh, and Google Chrome forces XSL output into UTF-8, while IE8 forces it into ISO 8859-1. The standard XSL tag for changing the encoding does not work in either browser. So that's fun.

    Don't forget that XSL will eat output whitespace in HTML/XML output modes entirely at random, making your output unreadable. The indent attribute won't work reliably so you'll have to parse your output document into a DOM tree and insert whitespace by hand (except on the topmost node level where at least one browser throws a fit if you try to insert text nodes).

    In the end I have to do a bunch of regex replacements before and after each transform, and insert/remove whitespace XML nodes before and after in order to get the output to look reasonable.

    Next time I need to do something like this my transform is being done entirely in JavaScript. Greater cross-browser compatibility and more control over things like output whitespace. Only time I am considering XSL is if 1) I only need to run it through one XSL transform engine ever 2) it is a very SIMPLE transform or 3) I will never need to look at or edit the source code of the output at any time.

  • Niko (unregistered) in reply to David

    Failing to see the wtf here, seems perfectly legit approach to me.

    And this is indeed what Blizzard's World of Warcraft armory does (or used to do couple of years ago, anyway).

  • AnonymousMouse (unregistered)

    Fairly OK approach when you consider it seems to have been generated by some CMS system. In fact if you want a CMS which can create an easy-peasy shopping website from a stock database having it generate pages like this seems more than sensible .... if you were coding it all by hand then, yeah, that would be weird.

  • (cs) in reply to David Kotsonis
    David Kotsonis:
    I'm reasonably certain that this constitutes grounds for a boycott.
    I'm way ahead of you dude. I've been boycotting Sketchers since forever.
  • Chris (unregistered)

    We had something almost as bad at my current employer. My predecessor was something of an XML and XSLT wonk, so he wrote his own "system" that converted Java objects into XML and applied XSLT transforms to produce a web page. This was spaghetti code rather than a properly designed framework, with individual Java classes serialised in an ad-hoc manner all over the place rather than via one definitive serialiser for each class - so the same object would result in different XML depending on how it made it's way through to the various Servlets at the front end.

    This whole mess required a 1.5GB heap space on each web server just to start, ran like a dog, was unstable and also unmaintainable. Needless to say, I put the thing into maintenance mode (which amounted to restarting the app servers when they regularly ran out of heap space) and replaced the system with something based on Spring and JSP.

  • (cs) in reply to oppeto
    oppeto:
    Well, a reason such design never took off is that it only works on Firefox. IE doesn't support XSL transforming*

    Which is the reason why www.skechers.com provides XHTML (with a HTML4 strict doctype) if you use a IE user-agent (just 'MSIE' as user-agent works).

    So the server needs to be able to do the template transformation itself anyway. At that point, it doesn't make sense to show something different to other browsers... unless you are skechers. (and yes, the default is XML, not the other way round)

    • As for Opera, Safari... I haven't tried.

    They're probably passing the XML to Firefox for client side processing, despite being able to do server side processing for IE, since a typical XSL processor is a very resource hungry beast and anything they can offload to the client is a win. The processor I'm familiar with (Saxon) is a memory and CPU hog that's hindered by arbitrary hard coded limits in a code base that looks like it was written by an unrepentant FORTRAN 77 programmer.

  • (cs)

    I could see, theoretically, how it could be an elegant technical design for an HTTP web service to output XML, and leave it up to the client whether to handle it as pure data or mark it up with XSLT for display.

    I can't see how that's a good design for a run-of-the-mill B2C e-commerce site.

  • Ryan O'Hara (unregistered)

    TRWTF is that the XML in the first file isn't even valid! They have no business putting the .xml extension on.

  • golddog (unregistered)

    Aren't Sketchers the pretentiously-overpriced-but-poorly-built tennis shoes that hipster idiots and teenage girls wear because they're cool, not because they're demonstrably worth the extra money?

    If so, that 'splains a thing or two...

  • Toby (unregistered) in reply to oppeto

    Replace "only works on Firefox" with "works in every major browser besides IE". This isn't 2001 ya know.

  • (cs)

    Is this where Alex got new job?

  • geoffrey (unregistered)

    This is a pretty ingenious solution for interfacing ERP systems with the web. If there's a better technology than XML for communicating between software systems, I have yet to see it.

  • (cs)

    Oh god it burns. It's like some pages here at my company that display "reports" that are pulled out of a database table, converted into XML, transformed with XSL and output to an ASP.NET label control as a string.

  • (cs) in reply to jc
    jc:
    Always knew such a thing would be theoretically possible but never found people crazy enough to actually do it. Kudos for this wonderful find :D
    It's wonderful. True separation between content and formatting. Particularly good is the fact that I don't have to maintain any part of it.
  • BentFranklin (unregistered)

    This site is highly innovative in its use of "shopping bag" instead of "shopping cart". Next time I'm at a store I'm going to try putting my items in a bag instead of a cart and see what happens.

  • Slartibartfast (unregistered)

    TRWTF is the assumption that doing something like this (that is, producing XML which is then transformed by the browser into XHTML using XSLT) was an "absurd" idea.

    Actually, I am wondering why not more high-profile sites use that pattern. It has some immediate benefits:

    • You don't have to transmit all that div-hell overhead that is required to create all this fancy design stuff your web designers have imagined WITH EACH REQUEST, even though it is pretty much always the same shit. Instead, the user fetches it ONCE on his first page request (in form of the XSLT stylesheet), subsequent requests only require sending the actual data (embedded in - hopefully - careful crafted XML structures that don't need all that design crap, but just need to represent the logical structure of your data), which results in a lot less overhead.
    • If you want to allow for syndication of your content (and a lot of sites nowadays want that, fortunately the days of "locking it all away" are coming to an end), you possibly don't even have to implement another interface for that - XML with a structure that represents the logical structure of your data, not the structure of the visible incarnation of that data in the browser, is pretty much perfect for being processed by third-party applications.
    • You have a clear distinction between the structured data that you want to display (the XML) and the visual appearance of that data (the result of the XSLT transformation), and you can thus easily alter the latter without having to touch the system that generates the former. Think Model/View separation - there you got it!

    As for browser support: ALL modern browsers (including IE) support XSLT transformation out of the box, I've tried it with a real project based on client-side XSLT (actually, a blog). For older versions (and such things as web crawlers like Googlebot, which also don't really seem to understand XML), it is easy to implement fully transparent server-side transformation in Apache as a fallback solution, triggered by the User-Agent string.

    Of course, not all sites could benefit in the same ways from client-side XML/XSLT (a prime example of a site perfectly suitable for such a technique is the already-mentioned WoW Armory, which explicitly wanted to allow easy syndication of its extremely well-structured, database-like content), but I consider this to be one of the least-well-known, but potentially most powerful tools in the toolbox of todays' web developer.

  • DoWTFWhileHavingCoffee (unregistered)

    Oh Jesus, my favorite. Hotshot hipster "programmers".

    My eyes. Pretty sure this WTF opened some sort of time hole and it is now Monday morning again.

    Damn you...

  • jexmex (unregistered)

    Just got done writing my first xslt. We get sports odds feeds from a API that returns XML. These change every few seconds. The most efficient approach is to load the xml result, transform ON THE SERVER SIDE with xslt, and cache the result for 1 minute (a year for archive data). All updates get done with ajax. I like the concept of xslt, but it was a bit of a pain to work with.

  • (cs)

    Almost all of the websites I'm responsible for use XSLT in this way, but on the server side. It works quite well, we use Symphony CMS.

  • (cs) in reply to Slartibartfast
    Slartibartfast:
    TRWTF is the assumption that doing something like this (that is, producing XML which is then transformed by the browser into XHTML using XSLT) was an "absurd" idea.

    Having worked on a system that did this, albeit server side, I can assure you that it's absurb.

    Slartibartfast:
    Actually, I am wondering why not more high-profile sites use that pattern. It has some immediate benefits: - You don't have to transmit all that div-hell overhead that is required to create all this fancy design stuff your web designers have imagined WITH EACH REQUEST, even though it is pretty much always the same shit. Instead, the user fetches it ONCE on his first page request (in form of the XSLT stylesheet), subsequent requests only require sending the actual data (embedded in - hopefully - careful crafted XML structures that don't need all that design crap, but just need to represent the logical structure of your data), which results in a lot less overhead.

    We already have stylesheets that abstract site styling from the structure. They're called Cascading Style Sheets, and they're very simple compared to the complexity of XSL. And if you think the differences in CSS implementation across browsers is a problem, you're going to be in a far worse kind of cross browser compatability hell with XSL support.

    Slartibartfast:
    - If you want to allow for syndication of your content (and a lot of sites nowadays want that, fortunately the days of "locking it all away" are coming to an end), you possibly don't even have to implement another interface for that - XML with a structure that represents the logical structure of your data, not the structure of the visible incarnation of that data in the browser, is pretty much perfect for being processed by third-party applications.

    If you cleanly separating the layers of your application, then serialising your data models as an RSS feed or as the response to a web service request will be straightforward. Meanwhile, you can still pass that same data model to a decent presentation layer technology for generating HTML web pages - and no, XSLT is not a sensible choice for a presentation layer for performance and complexity reasons.

    Slartibartfast:
    - You have a clear distinction between the structured data that you want to display (the XML) and the visual appearance of that data (the result of the XSLT transformation), and you can thus easily alter the latter without having to touch the system that generates the former. Think Model/View separation - there you got it!

    Why pay the cost of serialising your data model to some bespoke XML format, only for the presentation layer of your app or the client browser to convert it to another XML format (HTML)?

    Slartibartfast:
    As for browser support: ALL modern browsers (including IE) support XSLT transformation out of the box, I've tried it with a real project based on client-side XSLT (actually, a blog). For older versions (and such things as web crawlers like Googlebot, which also don't really seem to understand XML), it is easy to implement fully transparent server-side transformation in Apache as a fallback solution, triggered by the User-Agent string.

    I doubt you've done much cross browser testing. Either that or your transforms are trivial, as anything reasonably sophisticated depends on the varying completeness and quirks of the browsers complex and resource hungry XSLT engine.

    Slartibartfast:
    Of course, not all sites could benefit in the same ways from client-side XML/XSLT (a prime example of a site perfectly suitable for such a technique is the already-mentioned WoW Armory, which explicitly wanted to allow easy syndication of its extremely well-structured, database-like content), but I consider this to be one of the least-well-known, but potentially most powerful tools in the toolbox of todays' web developer.

    The WoW armoury has a very small set of elements, and is not comparable to the complex markup of a typical website.

  • Stabbitha (unregistered)

    Well, at least the site itself isn't WTFugly ...

  • Jan (unregistered) in reply to Xenious
    Xenious:
    Pony:
    Not sixth, seventh, dude.

    Fuck you. It is zero based. Get back on you vb script, looser.

    Thanks to you I won't find anything funnier on the internet today. Thanks for making me productive!

  • Neil (unregistered)

    A design like was the holy grail back when WAP was still considered viable. See http://cocoon.apache.org/.

  • fennec (unregistered)

    My first job with computers, in high school, was working on the local university's intranet. It used an XML-to-XSLT templating system. It wasn't all good, surely, and it wasn't all bad - there's some XSLTy stuff that's actually quite powerful.

    But the XSLT was at least done server-side: Apache Xerces and Xalan. Leaving the browser to do it is a recipe for silliness.

  • (cs) in reply to java.lang.Chris;
    java.lang.Chris;:
    Why pay the cost of serialising your data model to some bespoke XML format, only for the presentation layer of your app or the client browser to convert it to another XML format (HTML)?

    Why pay the "cost"? Because XSLT does a fucking amazing job at linking data together.

  • DWalker (unregistered) in reply to Xenious
    Xenious:
    Pony:
    Not sixth, seventh, dude.

    Fuck you. It is zero based. Get back on you vb script, looser.

    As opposed to tighter?

  • Ixitar (unregistered)

    Doesn't the act of posting this violate some non-disclosure agreement?

    I personally prefer doing XML transforms utilizing XQuery instead of XSLT, but that is me.

  • (cs) in reply to The Wolf
    The Wolf:
    java.lang.Chris;:
    Why pay the cost of serialising your data model to some bespoke XML format, only for the presentation layer of your app or the client browser to convert it to another XML format (HTML)?

    Why pay the "cost"? Because XSLT does a fucking amazing job at linking data together.

    If by "fucking amazing job" you really mean "a fucking amazing memory and CPU gobbling job using a gratuitous XML syntax from hell", then we can agree.

    Part of the problem with XSLT is also the skills shortage when it comes to finding people who can use it. With my employers previous system, where the page templates for their web apps were written in XSLT, they couldn't find any web developers that knew it. Fortunately, they found a highly intelligent PHP guy who was prepared to learn XSLT (not me I should add - I'm on the back end dev team).

    We've now switched to JSP for the presentation layer templates, and we can at least hire on the basis that a reasonably competent PHP monkey can be taught JSP and JSTL (with scriptlets disabled to stop them reverting to bad habits).

  • Cbuttius (unregistered)

    I didn't look at much of what you posted but this should be a Code SOD, not a feature article.

  • Mr. J (unregistered)

    Oh that brings back memories of a system I worked for. Being fresh out of uni, my mind was open to accept it as normal... Now however, I shudder.

    ... What's missing is the SQL Server stored procedures generating XML, returning it as a string stream, streaming straight out to the page client... and transform.

    shudders

  • Cbuttius (unregistered)

    I don't know what's wrong with the code because I don't do this kind of development (plus I haven't looked at it).

    If it has been auto-generated with a tool, maybe that makes it a bit less WTF'y. And perhaps it was? You weren't there...

  • (cs) in reply to java.lang.Chris;
    java.lang.Chris;:
    The Wolf:
    java.lang.Chris;:
    Why pay the cost of serialising your data model to some bespoke XML format, only for the presentation layer of your app or the client browser to convert it to another XML format (HTML)?

    Why pay the "cost"? Because XSLT does a fucking amazing job at linking data together.

    If by "fucking amazing job" you really mean "a fucking amazing memory and CPU gobbling job using a gratuitous XML syntax from hell", then we can agree.

    While it's true libxsl might struggle with 6000+ lines of XML, part of our job is to make sure that doesn't happen. Actually, come to think of it, what system wouldn't struggle with that much data?

    java.lang.Chris;:
    Part of the problem with XSLT is also the skills shortage when it comes to finding people who can use it. With my employers previous system, where the page templates for their web apps were written in XSLT, they couldn't find any web developers that knew it. Fortunately, they found a highly intelligent PHP guy who was prepared to learn XSLT (not me I should add - I'm on the back end dev team).

    We've now switched to JSP for the presentation layer templates, and we can at least hire on the basis that a reasonably competent PHP monkey can be taught JSP and JSTL (with scriptlets disabled to stop them reverting to bad habits).

    This is a legitimate problem, I've been responsible for training new developers; however it isn't really a problem with the technique itself.

  • James (unregistered)

    Actually, I ran it through IE8 and Google Chrome. IE8 gets an HTML4 Strict page with a lot of div tags and is rather mainstream. The Google Chrome browser gets full XML, XLST, etc. Chrome renders it extremely fast.

    What we are seeing is different outputs for different browsers all transformed on the server. Who knows what the original backend development is like, it could be all Java.

    Ruby on Rails can transform views on the fly, I don't think you can go to this extreme but maybe...

    It might not be evil to maintain on the backend, depending on what's actually powering the site.

Leave a comment on “Sketchy Skechers.com”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article