Sketchy Skechers.com

« Return to Article
  • Alex Papadimoulis 2012-01-26 01:47
    Posting comments before the article goes live!? Wha!? How?!

    Really, the only benefit of following @thedailywtf.
  • jc 2012-01-26 03:10
    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
  • Shenghi 2012-01-26 03:44
    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 2012-01-26 05:25
    This is sketchy at best
  • Jack 2012-01-26 06:57
    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 2012-01-26 06:58
    Fantastic, I even learned a new word today!
  • Xenious 2012-01-26 07:54
    sixth!

    captcha: Penis.
  • Pony 2012-01-26 07:56
    Not sixth, seventh, dude.
  • Xenious 2012-01-26 07:57
    Pony:
    Not sixth, seventh, dude.


    Fuck you. It is zero based. Get back on you vb script, looser.
  • oppeto 2012-01-26 08:21
    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 2012-01-26 08:39
    I'm reasonably certain that this constitutes grounds for a boycott.
  • Lester 2012-01-26 09:12
    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 2012-01-26 09:15
    Im fairly sure that the world of Warcraft armory does something similar?
  • Anon 2012-01-26 09:17
    My mistake, perhaps it was an older version but i distinctly remember being told it did this.
  • TheRider 2012-01-26 09:22
    Ahhhh! My eyes! The goggles, they do nothing!!!
  • David 2012-01-26 09:24
    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...
  • TGV 2012-01-26 09:29
    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...
  • The MAZZTer 2012-01-26 09:29
    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 2012-01-26 09:33
    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 2012-01-26 09:39
    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.
  • frits 2012-01-26 09:40
    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 2012-01-26 09:43
    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.
  • java.lang.Chris; 2012-01-26 09:48
    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.
  • Rootbeer 2012-01-26 09:55
    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 2012-01-26 10:09
    TRWTF is that the XML in the first file isn't even valid! They have no business putting the .xml extension on.
  • golddog 2012-01-26 10:10
    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 2012-01-26 10:10
    Replace "only works on Firefox" with "works in every major browser besides IE". This isn't 2001 ya know.
  • Nagesh 2012-01-26 10:20
    Is this where Alex got new job?
  • geoffrey 2012-01-26 10:24
    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.

  • ObiWayneKenobi 2012-01-26 10:25
    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.
  • dkf 2012-01-26 10:25
    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 2012-01-26 10:28
    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 2012-01-26 10:28
    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 2012-01-26 10:38
    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 2012-01-26 10:39
    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.
  • The Wolf 2012-01-26 10:42
    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.
  • java.lang.Chris; 2012-01-26 10:44
    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 2012-01-26 10:46
    Well, at least the site itself isn't WTFugly ...
  • Jan 2012-01-26 10:48
    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 2012-01-26 10:50
    A design like was the holy grail back when WAP was still considered viable. See http://cocoon.apache.org/.
  • fennec 2012-01-26 10:55
    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.
  • The Wolf 2012-01-26 10:55
    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 2012-01-26 11:01
    Xenious:
    Pony:
    Not sixth, seventh, dude.


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


    As opposed to tighter?
  • Ixitar 2012-01-26 11:06
    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.
  • java.lang.Chris; 2012-01-26 11:08
    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 2012-01-26 11:10
    I didn't look at much of what you posted but this should be a Code SOD, not a feature article.
  • Mr. J 2012-01-26 11:11
    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 2012-01-26 11:12
    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...
  • The Wolf 2012-01-26 11:13
    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 2012-01-26 11:25
    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.
  • Crisw 2012-01-26 11:33
    I've actually seen this done in the wild.


    It's horrifying.
  • Lockwood 2012-01-26 11:39
    TGV:
    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...


    Yo dawg, I heard you like XSLTception...
  • Slartibartfast 2012-01-26 11:40
    java.lang.Chris;:
    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.

    Actually, CSS does a bad job at separating visual stuff from logical structure, because creating a lot of visual effects requires you to pack thisandthat into a span, then put it with something else together into a div, then put that into another div with a little-bit-different style and so on and so on, just in order for you to get all the necessary HTML elements to apply your precious styles to which you need for your desired effect.

    Just take a look at any fancy-styled modern website and count the number of elements that actually serve to structure the information for display versus those that do not further add any structuring, but are only used to apply visual styling. The latter are almost always in the majority.

    java.lang.Chris;:
    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.

    XSLT doesn't provide the whole transformation to the "presentation layer", just the transformation from purely logically-structured XML to XHTML, which is usually already different enough. The final step towards the actual site displayed in the browser is still done via CSS.

    And why exactly is XSLT not suitable for performance reasons? The really neat thing about XSLT is that you can choose to run it client-side on a lot of clients, which offloads the load from your server to your clients. Scales just fine with more clients, since more clients equal more processing power at your disposal. And I assume "complexity reasons" equate to "web guys can't write XSLT" - may be true, and may be a real blocker in practice. But that's why I consider knowledge about XSLT to be an important tool in every web developers' toolbox, which should be just as well-known as CSS.

    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)?

    Because that cost to create the XML is actually negligible, if your internal data structures are good. I think you called it "straightforward" in the quote above.

    java.lang.Chris;:
    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.

    True, I actually haven't used every feature available in XSLT. But the basic stuff definitely works the same on all browsers, and you can come a long way with that. Remember, XSLT is just generating the XHTML, which is then styled using CSS just as usual.

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

    Depends on the website. When you look at this site for example, it is also based on a very small set of elements - a navigation, stories, comments, ads, that pretty much sums it up (with each of them possibly having sub-elements of course). There are for sure sites which explode "horizontally" in terms of number of different elements, like portal sites etc., but I would never approach such a site with a client-side XSLT technique. I'm far from proclaiming that XSLT is the right tool for every possible job.

    But: what the WoW armory definitely had was an extremely sophisticated visual design, way more complex than the average website out there has. That stuff was mostly realized using classic CSS features, of course in combination with XSLT to generate the HTML structures required for the CSS to attach to and do its magic. This way, the hell of divs and divs-inside-more-divs was created just at display time, but didn't have to be transferred to the user on every page request, which resulted in very clean and small pages with extremely impressive visuals.
  • Ben Jammin 2012-01-26 11:44
    Jan:
    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!


    Yeah, I did a spit-take on my coffee.
  • Ralph 2012-01-26 11:47
    java.lang.Chris;:
    a typical XSL processor is a very resource hungry beast and anything they can offload to the client is a win.
    'scuse me, my processor is not yours to appropriate, kthxbai
  • Mrs. Nagesh 2012-01-26 11:49
    Chris:
    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.

    "..., ran like a dog, ..."

    Greyhound?
  • Goon 2012-01-26 11:51
    Wow, the only other actual page I know of using XML + XSL stuff is the Goonswarm's killboard for Eve Online. https://killboard.goonfleet.com/
  • Ralph 2012-01-26 11:54
    Slartibartfast:
    it is easy to implement fully transparent server-side transformation in Apache as a fallback solution, triggered by the User-Agent string.
    If you're looking at the User-Agent string, you're Doing It Wrong (TM). Yes, I mean all of you "test it on the top 4 browsers" idiots. If you already have the code to do it on the server, do it on the server for everyone. If there's a B2B need to share raw XML etc. do that through a separate URL or URL parameter.
  • Slartibartfast 2012-01-26 11:58
    Ralph:
    Slartibartfast:
    it is easy to implement fully transparent server-side transformation in Apache as a fallback solution, triggered by the User-Agent string.
    If you're looking at the User-Agent string, you're Doing It Wrong (TM). Yes, I mean all of you "test it on the top 4 browsers" idiots. If you already have the code to do it on the server, do it on the server for everyone. If there's a B2B need to share raw XML etc. do that through a separate URL or URL parameter.

    I should add to clarify: The way that this "filter" works is of course "There's this list of browsers and versions that we tested and work well with the transform, so we'll give them the XML, and all others get pre-transformed XHTML".
  • TheRealAaron 2012-01-26 12:00
    Actually it is. You implicitly agree to this any time you visit a website. Maybe most sites don't use your processor to render XSLT but they use it one way or another—HTML rendering, JavaScript execution, CSS box model calculations, etc. If you can't spare the processing power it takes to render a page in a browser, you can't afford to be browsing the web. Honestly, processor power on a typical PC is about as close to free as things get.
  • Ralph 2012-01-26 12:06
    TheRealAaron:
    Actually it is. You implicitly agree to this any time you visit a website. Maybe most sites don't use your processor to render XSLT but they use it one way or another—HTML rendering, JavaScript execution, CSS box model calculations, etc. If you can't spare the processing power it takes to render a page in a browser, you can't afford to be browsing the web. Honestly, processor power on a typical PC is about as close to free as things get.
    Nope.

    I explicitly don't agree.

    And it isn't because of the "cost" of CPU time. I'm happy to process data (HTML, CSS) on my machine. You do not get to run your executable code on my machine. It's mine not yours. Get it now?
  • wbrianwhite 2012-01-26 12:10
    BentFranklin:
    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.



    The items will stay in the bag just fine, thanks to gravity. Shopping with bags predates shopping with carts by several thousand years. You can use baskets for shopping as well.
  • hobbes 2012-01-26 12:13
    I have had the "pleasure" of ordering from Sketchers before. A week and a half prior to my daughter starting second grade at a new school, she was terrified. All she wanted were her "special shoes" ( the bella ballerina shoes, for those keeping score at home ). Figuring a week and a half is more than enough time to get the shoes in, I made the mistake of ordering them from their website ( sketchers ). 10 business days to ship. No other shipping options.

    Once I found that out ( the ording process didn't make that clear until after the bill was paid ), I spent a couple days trying to get a hold of someone, to see if we could expedite that. When I finally did get a hold of someone, they seemed completely uninterested and, frankly, annoyed that I had called. Ultimately, they were unable to do anything for me. So I canceled my order, and ordered from zappos instead. Shoes cost slightly less and were at my door the next day.

    What's funny is I canceled my order with sketchers, got a refund and everything. Then, about a week and a half later ( a day after school started, for the record ), I received a second pair of shoes. Given my treatment by the sketcher folks, I didn't feel the need to return them.
  • AN AWESOME CODER 2012-01-26 12:14
    David:
    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?


    I almost fell for this trolling.
  • wbrianwhite 2012-01-26 12:22
    James:
    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.


    Yeah. It will be very simple to transform this into HTML 5 now won't it?

    I also don't know what you mean by vanilla. Blank xmlns attributes all over the place. span onclick="location.href='/women#Color=Black'" class="swatch swatch-Black"><a href="/women#Color=Black">Black</a></span
    WTF would you wrap an href in an inline javascript function that turns the href into... an href?

    And images that all point to blank images, and have their background image style set to the image they should just be pointing to? That is severe abuse of basic anchor and image tags
    <img alt="" height="140" width="312" style="background-image:url(http://cdn2.skechers-usa.com/c/u/SNP3033_FoursquareMayor_K_18s7i_ySaWe6kq5IO29qxOIlo=.jpg)" src="/c/spc.png"></a>
    </div>
  • wbrianwhite 2012-01-26 12:26
    Slartibartfast:

    Depends on the website. When you look at this site for example, it is also based on a very small set of elements - a navigation, stories, comments, ads, that pretty much sums it up (with each of them possibly having sub-elements of course). There are for sure sites which explode "horizontally" in terms of number of different elements, like portal sites etc., but I would never approach such a site with a client-side XSLT technique. I'm far from proclaiming that XSLT is the right tool for every possible job.


    Yes, this site is fairly simple. Simple enough to easily write it as HTML5, which actually has semantic tags for articles, sections, etc. HTML5 is the 2012+ solution to lots of non-semantic tags (plus mobile compatibility, plus new user interface elements, plus local storage, etc.). XML/XSLT is the 2004 "solution" to the same problem.
  • AN AWESOME CODER 2012-01-26 12:28
    Slartibartfast:

    And why exactly is XSLT not suitable for performance reasons? The really neat thing about XSLT is that you can choose to run it client-side on a lot of clients, which offloads the load from your server to your clients. Scales just fine with more clients, since more clients equal more processing power at your disposal. And I assume "complexity reasons" equate to "web guys can't write XSLT" - may be true, and may be a real blocker in practice. But that's why I consider knowledge about XSLT to be an important tool in every web developers' toolbox, which should be just as well-known as CSS.


    ::WHISTLE BLOW::

    You're missing the point. The "power and your disposal" that you're offloading to clients is work that doesn't need to be performed repeatedly in the first place.

    XSLT should not take place at this layer. I've seen it done (and I've even done it myself in the past) and it's a terrible idea.
  • Jim 2012-01-26 12:28
    Mr. J:
    ... What's missing is the SQL Server stored procedures generating XML


    SQL Server 2000, natch.
  • Dennis 2012-01-26 12:32
    You do have the right to point your browser somewhere else, or use NoScript. No one cares about your whining.
  • java.lang.Chris; 2012-01-26 12:35
    Slartibartfast:
    java.lang.Chris;:
    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.

    Actually, CSS does a bad job at separating visual stuff from logical structure, because creating a lot of visual effects requires you to pack thisandthat into a span, then put it with something else together into a div, then put that into another div with a little-bit-different style and so on and so on, just in order for you to get all the necessary HTML elements to apply your precious styles to which you need for your desired effect.

    Just take a look at any fancy-styled modern website and count the number of elements that actually serve to structure the information for display versus those that do not further add any structuring, but are only used to apply visual styling. The latter are almost always in the majority.


    I generally find that the degree of structural markup increases as the readability of a webpage decreases, which may suggest it's a design and implementation issue. As for CSS selectors, I see a lot of style sheets that don't use them properly, leading to a lot of duplication in the style sheet and avoidable div or span tags in the (X)HTML.

    Slartibartfast:
    java.lang.Chris;:
    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.

    XSLT doesn't provide the whole transformation to the "presentation layer", just the transformation from purely logically-structured XML to XHTML, which is usually already different enough. The final step towards the actual site displayed in the browser is still done via CSS.


    You haven't seen XSLT used as a full blown templating language for a web presentation layer by the sounds of it. I have several times, and while XSLT offers many of the same facilities as JSP or Velocity it does so in a far more complex and verbose way.

    Slartibartfast:
    And why exactly is XSLT not suitable for performance reasons? The really neat thing about XSLT is that you can choose to run it client-side on a lot of clients, which offloads the load from your server to your clients. Scales just fine with more clients, since more clients equal more processing power at your disposal. And I assume "complexity reasons" equate to "web guys can't write XSLT" - may be true, and may be a real blocker in practice. But that's why I consider knowledge about XSLT to be an important tool in every web developers' toolbox, which should be just as well-known as CSS.


    The implementations across browsers vary in completeness and consistency. Regardless of whether it's run client or servers side, the weird recursively functional way that XSLT works and the dependence on a potentially large and memory costly object graph are a hindrance to performance. I also wonder what search engine spiders like Googlebot make of something that serves up spaghetti like the Skechers site.

    Slartibartfast:
    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)?

    Because that cost to create the XML is actually negligible, if your internal data structures are good. I think you called it "straightforward" in the quote above.


    I was referring to the relatively straightforward conversion to simpler formats such as an RSS feed.

    Slartibartfast:
    java.lang.Chris;:
    The WoW armoury has a very small set of elements, and is not comparable to the complex markup of a typical website.

    Depends on the website. When you look at this site for example, it is also based on a very small set of elements - a navigation, stories, comments, ads, that pretty much sums it up (with each of them possibly having sub-elements of course). There are for sure sites which explode "horizontally" in terms of number of different elements, like portal sites etc., but I would never approach such a site with a client-side XSLT technique. I'm far from proclaiming that XSLT is the right tool for every possible job.

    But: what the WoW armory definitely had was an extremely sophisticated visual design, way more complex than the average website out there has. That stuff was mostly realized using classic CSS features, of course in combination with XSLT to generate the HTML structures required for the CSS to attach to and do its magic. This way, the hell of divs and divs-inside-more-divs was created just at display time, but didn't have to be transferred to the user on every page request, which resulted in very clean and small pages with extremely impressive visuals.


    I'm not as familiar with the WoW armoury as you clearly are, but this does sound like a more sensible use of XSLT than most similar ones I've come across. And I guess I should make it clear that while I think XSLT was badly implemented, the idea was sound, and it's certainly less of a nightmare than what preceded it (Google for DSSSL if you're not familiar with it). Personally, I much prefer to do server side processing with a DOM parser, where the XPath sub-language that comes from XSLT is a very elegant feature.
  • java.lang.Chris; 2012-01-26 12:38
    Mrs. Nagesh:
    Chris:
    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.

    "..., ran like a dog, ..."

    Greyhound?


    It's a British expression that describes something which runs more like an asthmatic Dachshund with only two legs than a thoroughbred Greyhound.
  • Slartibartfast 2012-01-26 12:43
    AN AWESOME CODER:
    You're missing the point. The "power and your disposal" that you're offloading to clients is work that doesn't need to be performed repeatedly in the first place.

    But it IS DONE repeatedly, whether you use XSLT or not. Someone has to generate the HTML at some point, whether that's you on your server (for each and every client) or every client, and whether that is via XSLT or by any other means. The only exception can be made for stuff you can pull out of your full/partial-page-cache server-side. In that case, there might indeed be a point in saying "I do it once for all the clients" - but the success rate of that strategy heavily depends on how dynamic your content is. And even then, it might be perfectly possible to balance that investment of (client-side!) processing power when using XSLT against the time saved during page transmission due to less overhead when using XSLT.
  • Klimax 2012-01-26 12:45
    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.


    Not completely correct. In IE9 in dev tools force identification to be of Google Chrome and site will sent XML+XSLT, which is rendered correctly by IE9. However IE will show you already transformed code. They also send WTF to Opera.
  • geoffrey 2012-01-26 12:48
    hobbes:
    I have had the "pleasure" of ordering from Sketchers before. A week and a half prior to my daughter starting second grade at a new school, she was terrified. All she wanted were her "special shoes" ( the bella ballerina shoes, for those keeping score at home ). Figuring a week and a half is more than enough time to get the shoes in, I made the mistake of ordering them from their website ( sketchers ). 10 business days to ship. No other shipping options.

    Once I found that out ( the ording process didn't make that clear until after the bill was paid ), I spent a couple days trying to get a hold of someone, to see if we could expedite that. When I finally did get a hold of someone, they seemed completely uninterested and, frankly, annoyed that I had called. Ultimately, they were unable to do anything for me. So I canceled my order, and ordered from zappos instead. Shoes cost slightly less and were at my door the next day.

    What's funny is I canceled my order with sketchers, got a refund and everything. Then, about a week and a half later ( a day after school started, for the record ), I received a second pair of shoes. Given my treatment by the sketcher folks, I didn't feel the need to return them.


    So you're using perceived mistreatment by a party to justify stealing from them. That speaks wonders to your character.
  • Ken B. 2012-01-26 12:56
    oppeto:
    Well, a reason such design never took off is that it only works on Firefox. IE doesn't support XSL transforming*

    ...

    * As for Opera, Safari... I haven't tried.
    Well, by "only works in Firefox", I assume what you really mean is "doesn't work in IE".

    Fortunately (FSVO), if the User-Agent setting in the HTTP request says that it's IE, the server returns a completely different result.

    And the XML/XSL version shows up correctly in Safari and Chrome. (I don't have Opera on any system I currently use.)
  • ¯\(°_o)/¯ I DUNNO LOL 2012-01-26 12:57
    I particularly appreciate how it barfs a bunch of javascript to the page, then immediately replaces it with a big image with a "Play" button in the middle of it.
  • CowboyBarney 2012-01-26 13:01
    hobbes:
    I have had the "pleasure" of ordering from Sketchers before. A week and a half prior to my daughter starting second grade at a new school, she was terrified. All she wanted were her "special shoes" ( the bella ballerina shoes, for those keeping score at home ). Figuring a week and a half is more than enough time to get the shoes in, I made the mistake of ordering them from their website ( sketchers ). 10 business days to ship. No other shipping options.

    Once I found that out ( the ording process didn't make that clear until after the bill was paid ), I spent a couple days trying to get a hold of someone, to see if we could expedite that. When I finally did get a hold of someone, they seemed completely uninterested and, frankly, annoyed that I had called. Ultimately, they were unable to do anything for me. So I canceled my order, and ordered from zappos instead. Shoes cost slightly less and were at my door the next day.

    What's funny is I canceled my order with sketchers, got a refund and everything. Then, about a week and a half later ( a day after school started, for the record ), I received a second pair of shoes. Given my treatment by the sketcher folks, I didn't feel the need to return them.


    Ironically, didn't Zappos just get hacked with 24 million users at risk? (http://gma.yahoo.com/video/money-26594258/zappos-com-hacked-24-million-at-risk-27904921.html). Maybe if they had web developers that could convert xml to spanish to html like sketchers does, this never would have happened.

    *shakes head*

    Queue the "My son converted xml to spanish once and I can assure you, it's no laughing matter" comments...
  • Mason Wheeler 2012-01-26 13:09
    The Wolf:
    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?


    ...what?

    6000 lines is nothing on modern hardware. Heck, the Delphi compiler can chew through that in literally a fraction of a second. Any parser worth the name, for pretty much any language won't even blink at 6KLOC. (Assuming, of course, that you're not using a broken language such as C++ where parsing itself can be a Turing-complete task and so can take an arbitrary amount of time even on small inputs.)
  • Christopher 2012-01-26 13:20
    Ah, but with zero-based indices, comment 0 is still the first comment, and comment 6 is the seventh. Get back to school, tighter.
  • verisimilidude 2012-01-26 13:21
    PIPA Request: You have posted copyrighted code that (may) belong to someone else. Your DNS records are being removed as well as the DNS records of all sites you link to
  • dgvid 2012-01-26 13:25
    Mrs. Nagesh:
    Chris:
    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.

    "..., ran like a dog, ..."

    Greyhound?

    Yes, like a greyhound. It was blazingly fast, but only for 30 seconds at a stretch, and it slept 16 hours a day.
  • Klimax 2012-01-26 13:25
    Ken B.:
    oppeto:
    Well, a reason such design never took off is that it only works on Firefox. IE doesn't support XSL transforming*

    ...

    * As for Opera, Safari... I haven't tried.
    Well, by "only works in Firefox", I assume what you really mean is "doesn't work in IE".

    Fortunately (FSVO), if the User-Agent setting in the HTTP request says that it's IE, the server returns a completely different result.

    And the XML/XSL version shows up correctly in Safari and Chrome. (I don't have Opera on any system I currently use.)


    By "Doesn't work in IE" you mean "dosen't work in IE8 and below" (IE8 is probably as I didn't test it)
  • Paul Neumann 2012-01-26 13:25
    [quote user="Ralph"][quote user="java.lang.Chris;"
    a typical XSL processor is a very resource hungry beast and anything they can offload to the client is a win.[/quote]
    'scuse me, my processor is not yours to appropriate, kthxbai[/quote]
    If you're consuming my data, than it certainly is. Would you rather I send you a gif so your processor doesn't have to process the html dom as well?
  • hobbes 2012-01-26 13:30
    geoffrey:
    hobbes:
    I have had the "pleasure" of ordering from Sketchers before. A week and a half prior to my daughter starting second grade at a new school, she was terrified. All she wanted were her "special shoes" ( the bella ballerina shoes, for those keeping score at home ). Figuring a week and a half is more than enough time to get the shoes in, I made the mistake of ordering them from their website ( sketchers ). 10 business days to ship. No other shipping options.

    Once I found that out ( the ording process didn't make that clear until after the bill was paid ), I spent a couple days trying to get a hold of someone, to see if we could expedite that. When I finally did get a hold of someone, they seemed completely uninterested and, frankly, annoyed that I had called. Ultimately, they were unable to do anything for me. So I canceled my order, and ordered from zappos instead. Shoes cost slightly less and were at my door the next day.

    What's funny is I canceled my order with sketchers, got a refund and everything. Then, about a week and a half later ( a day after school started, for the record ), I received a second pair of shoes. Given my treatment by the sketcher folks, I didn't feel the need to return them.


    So you're using perceived mistreatment by a party to justify stealing from them. That speaks wonders to your character.
    What, that I'm an asshole? Hell, you didn't need my little story up there to tell you that, *I* would have told you were you that curious.
  • AN AWESOME CODER 2012-01-26 13:32
    [quote user="Paul Neumann"][quote user="Ralph"][quote user="java.lang.Chris;"
    a typical XSL processor is a very resource hungry beast and anything they can offload to the client is a win.[/quote]
    'scuse me, my processor is not yours to appropriate, kthxbai[/quote]
    If you're consuming my data, than it certainly is. Would you rather I send you a gif so your processor doesn't have to process the html dom as well?[/quote]

    This is the dumbest rebuttal ever. A gif cannot represent structure, events, or anything that HTML does. There are clear benefits to serving HTML instead of an image of a website to the receiver. There is absolutely no benefit in serving XSLT instead of HTML to the receiver.

    Would you rather me send you a binary gif through an img tag directly, or embed an encoded string representation of a gif and have your browser do all of the work?

  • Sanity 2012-01-26 13:33
    oppeto:
    Well, a reason such design never took off is that it only works on Firefox. IE doesn't support XSL transforming*


    Actually, last I checked, IE and Firefox supported it -- and Chrome appears to -- but other random browsers, like Konqueror, did not.

    Also, I do actually see a point here. If HTML doesn't provide enough of a semantic context for the HTML itself to be the API, then you need an XML or JSON API anyway -- though of course, there seem to be a lot of people these days who think HTML does provide enough semantics, and they have a point. But if your API is going to be non-HTML, and it's going to provide all the same information -- especially if it's going to provide it in a more bandwidth-efficient way -- then having the client do the work of actually applying a template makes sense.

    Having the server do the transformation for browsers which don't support doing it themselves also makes sense -- XSLT has plenty of libraries anyway, and this way you get the best of both worlds. It's like having the server support gzipping the page or not.

    Other sites that do this kind of thing without ending up on thedailywtf. Twitter servers most of its content in JSON these days -- twitter.com/thedailywtf becomes twitter.com/#!/thedailywtf, so the JavaScript on 'twitter.com' interprets any hashtag URL, uses Twitter's own JSON API, and manages any HTML templates itself.

    So why is reinventing the wheel with JavaScript, of all things, not WTF-worthy, but using the browser's native XSLT support is automatically a WTF? Is it because anything XML translates as WTF?

    I'm not defending the sketchers site -- it does, in fact, look sketchy, and not at all like a site that's taking advantage of this (they use JavaScript to generate XSLT themselves) -- but I don't see this as a WTF in its own right. Not how I'd do things (HTML is probably rich enough), but not automatically a WTF.
  • Anon 2012-01-26 13:42
    ObiWayneKenobi:
    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.


    Bonus points for leaving ViewState enabled on that label.
  • Paul Neumann 2012-01-26 13:42
    AN AWESOME CODER:
    Paul Neumann:
    Ralph:
    java.lang.Chris;:

    a typical XSL processor is a very resource hungry beast and anything they can offload to the client is a win.

    'scuse me, my processor is not yours to appropriate, kthxbai

    If you're consuming my data, than it certainly is. Would you rather I send you a gif so your processor doesn't have to process the html dom as well?


    This is the dumbest rebuttal ever. A gif cannot represent structure, events, or anything that HTML does. There are clear benefits to serving HTML instead of an image of a website to the receiver. There is absolutely no benefit in serving XSLT instead of HTML to the receiver.


    Point, set, match.

    The "structure, events, or anything that HTML does" is exactly the processing I was referring to. The actual troll comes in at the amount of processing required to display the gif. There is no such thing as a free lunch.

    AN AWESOME CODER:
    Would you rather me send you a binary gif through an img tag directly, or embed an encoded string representation of a gif and have your browser do all of the work?


    Wrap it up in base64 and inline it with the css so I don't have to make multiple requests to the server, please.

    CAPTCHA: conventio -- The commings and goings of monks.
  • Berend de Boer 2012-01-26 13:44
    I don't get this. This seems to be a very legitimate and neat way of doing things. Band-width saving spitting out of XML, save server cpu by distributing rendering over all clients, it loads fast?

    Really, in many years this is the first article where I have to say nothing to see here.
  • crism 2012-01-26 13:48
    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...

    Originally, the plan was a subset of DSSSL expressed as a Scheme dialect (search for dsssl-o). No one cared. Changing the parentheses to pointy brackets suddenly caused it to be widely accepted… It came down to marketing, really. Sad, but true.

    Captcha: wisi (not always wig)
  • Dave-Sir 2012-01-26 13:53
    java.lang.Chris;:
    Mrs. Nagesh:
    "..., ran like a dog, ..."

    Greyhound?

    It's a British expression that describes something which runs more like an asthmatic Dachshund with only two legs than a thoroughbred Greyhound.

    It's a common expression on this side of the pond, as well. However, it's one of those expressions that's not particularly well thought-out. Most dogs I'm familiar with (the healthy ones, at least) run quite fast.

    Another example: Anyone who describes a good night's sleep as "sleeping like a baby" never had one.
  • Jack 2012-01-26 13:54
    Berend de Boer:
    I don't get this. This seems to be a very legitimate and neat way of doing things. Band-width saving spitting out of XML, save server cpu by distributing rendering over all clients, it loads fast?

    Really, in many years this is the first article where I have to say nothing to see here.
    Except it doesn't work.

    So, literally, nothing to see here. Or at least nothing I'd want to see. Just some script barf all over the page.
  • Mike 2012-01-26 13:59
    This style of code (right down to the dynamically generated javascript) was the standard for about 10 years at the Fortune 500 company I work at. I spent the better part of a year maintaining a mess very similar to the Skechers site and It's all exactly as horrifying as it seems.

    Our company has thankfully killed this standard and is busy writing the replacement. What horrifies me about Skechers is that it's fairly new and not 5 years old.
  • AN AWESOME CODER 2012-01-26 14:02
    Paul Neumann:
    AN AWESOME CODER:
    Paul Neumann:
    Ralph:
    java.lang.Chris;:

    a typical XSL processor is a very resource hungry beast and anything they can offload to the client is a win.

    'scuse me, my processor is not yours to appropriate, kthxbai

    If you're consuming my data, than it certainly is. Would you rather I send you a gif so your processor doesn't have to process the html dom as well?


    This is the dumbest rebuttal ever. A gif cannot represent structure, events, or anything that HTML does. There are clear benefits to serving HTML instead of an image of a website to the receiver. There is absolutely no benefit in serving XSLT instead of HTML to the receiver.


    Point, set, match.

    The "structure, events, or anything that HTML does" is exactly the processing I was referring to. The actual troll comes in at the amount of processing required to display the gif. There is no such thing as a free lunch.



    This argument is sillier than you've made it out to be, but you're still missing the point. I buy that this solution isn't terrible if it was cheap and the datasource is decently formatted XML from some other Enterprisey system. What I don't buy is what you seem to be trying to push -- this is the way it SHOULD be done, because it saves YOU money.

    2 step processing still requires 2 steps of processing. You're using the fact that "the client has to do the processing, not my server!" as some magical scalability and performance feature. It's not. The fact that you can offload work to a client doesn't make it proper.

    XSTL has it's place, and the outter most presentation layer is not it.

    Paul Neumann:

    AN AWESOME CODER:

    Wrap it up in base64 and inline it with the css so I don't have to make multiple requests to the server, please.



    Multiple requests? There's a single request for the gif once, unless you choose to not set proper caching headers. In the latter case, please don't make any other arguments about "saving bandwidth" or "offloading work to clients". Embedded content is processed every single time, in this case even if the HTML is cached. The external gif is loaded once.

    Also, it's 2012. Congrats, you saved 12ms by embedding the image instead of just using an <img/> tag. And what zero-time tool did you use to encode the image?
  • jMerliN 2012-01-26 14:03
    We already have better tools for doing all of this.

    1. You cache HTML pages (small ones at that) and javascript on the client.
    2. You send data over in JSON via XHR requests.
    3. You use javascript-based templates and processing to render the data.

    You get major benefits, which include:

    1. It's performant with no real effort.
    2. It's very portable when you use JS frameworks (jQuery/underscore/backbone, etc).
    3. You can trivially gzip large JSON responses and lower bandwidth (and this is easily added in at any time without breaking the website, since it's done by the webserver).
    4. It's incredibly simple to maintain, extend, secure, debug, and lends itself to a very easy testability story. This is primarily because you have an extreme separation of concerns at every level.
    5. The JSON services (RESTful or however else you would care to design them) can easily be published as an API using JSONP for anyone else to use.

    This entire story is one gigantic WTF. Also, CAPTCHA: haero. The developers of this system are my haeros.
  • Nagesh 2012-01-26 14:04
    wbrianwhite:
    BentFranklin:
    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.



    The items will stay in the bag just fine, thanks to gravity. Shopping with bags predates shopping with carts by several thousand years. You can use baskets for shopping as well.


    Bags not allowed to take inside store. Leave bag with security, get token and go to store. Shopping cart allowed inside store.
  • Don 2012-01-26 14:14
    geoffrey:
    hobbes:
    What's funny is I canceled my order with sketchers, got a refund and everything. Then, about a week and a half later ( a day after school started, for the record ), I received a second pair of shoes. Given my treatment by the sketcher folks, I didn't feel the need to return them.


    So you're using perceived mistreatment by a party to justify stealing from them. That speaks wonders to your character.

    And just how is this "stealing"? He told them to not send the shoes and they sent them anyway. Obviously, it was a gift from the company to make up for the poor treatment he received from their representative. It would practically be rude for him to refuse their peace offering.
  • Zuba Dalama 2012-01-26 14:25
    Previous version of armory did.
  • Nick 2012-01-26 14:28
    norsetto:
    Fantastic, I even learned a new word today!

    Apparently so did the person who posted right after you. Those captcha's can be very informative.
  • Paul Neumann 2012-01-26 14:30
    AN AWESOME CODER:
    (snip...)

    This argument is sillier than you've made it out to be, but you're still missing the point. I buy that this solution isn't terrible if it was cheap and the datasource is decently formatted XML from some other Enterprisey system. What I don't buy is what you seem to be trying to push -- this is the way it SHOULD be done, because it saves YOU money.


    Umm, where is it that you have knowledge of how their data is being sourced? Also, yes! Saving money is exactly why we all have jobs. Anything done by a computer can equally well be done by man, given a sufficient pool of workers. Computers make it cheaper!

    AN AWESOME CODER:
    2 step processing still requires 2 steps of processing. You're using the fact that "the client has to do the processing, not my server!" as some magical scalability and performance feature. It's not. The fact that you can offload work to a client doesn't make it proper.

    XSTL has it's place, and the outter most presentation layer is not it.


    Yes, pipelining the data generated elsewhere to the client to have it processed according to the number of requests received is "some magical scalability and performance feature."

    AN AWESOME CODER:
    (snip...)

    Multiple requests? There's a single request for the gif once, unless you choose to not set proper caching headers. In the latter case, please don't make any other arguments about "saving bandwidth" or "offloading work to clients". Embedded content is processed every single time, in this case even if the HTML is cached. The external gif is loaded once.

    Also, it's 2012. Congrats, you saved 12ms by embedding the image instead of just using an <img/> tag. And what zero-time tool did you use to encode the image?


    Perhaps you are new to the interwebs? Here is a guide you should find most useful: http://go at. cx
  • giony 2012-01-26 14:38
    You are certainly correct. The way these guys have done it though completely eliminates the entire benefit that XSLT could have given them.
    For the first webpage, the XML should have been at most few lines long: the products that they sell.

    The rest was just plain static HTML which should have stayed that way.

    Proper use of XSLT transformation can reduce the traffic by more than 50% when used properly.

    the key word here is: "when used properly". these guys have not done that for sure.
  • Kuba 2012-01-26 14:58
    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.
    Here's probably why Googlebot doesn't do XSLT: it'd be fairly easy to create a "big" site full of "random" on-the-fly generated content. XSLT would then implement a computation that you want, and would feed the results back to your server in the HTML requests coming from such a crawl. Presto, you get google to do your computations for you, for free.
  • wbrianwhite 2012-01-26 14:59
    Berend de Boer:
    I don't get this. This seems to be a very legitimate and neat way of doing things. Band-width saving spitting out of XML, save server cpu by distributing rendering over all clients, it loads fast?

    Really, in many years this is the first article where I have to say nothing to see here.


    So you have a lot of people who design HTML layouts at your company who are also expert at XSLT? Using this pattern requires middling-to-good programmers just to do basic layout changes. And then you get awesome problems like NaN not being tested correctly in the xsl causing your home page not to render.
  • Spewin Coffee 2012-01-26 15:06
    What gets me is that Firefox renders XSLT. That means there is a whole XSLT processing engine baked into the browser just for websites like this. How many MB of wasted hard drive space does such support take up?
  • Anketam 2012-01-26 15:10
    Dave-Sir:
    java.lang.Chris;:
    Mrs. Nagesh:
    "..., ran like a dog, ..."

    Greyhound?

    It's a British expression that describes something which runs more like an asthmatic Dachshund with only two legs than a thoroughbred Greyhound.

    It's a common expression on this side of the pond, as well. However, it's one of those expressions that's not particularly well thought-out. Most dogs I'm familiar with (the healthy ones, at least) run quite fast.

    Another example: Anyone who describes a good night's sleep as "sleeping like a baby" never had one.
    Or my favorite "Sweating like a pig" (pigs are barely capable of producing sweat, they have to wallow in mud to keep cool).
  • Kuba 2012-01-26 15:10
    hobbes:
    What's funny is I canceled my order with sketchers, got a refund and everything. Then, about a week and a half later ( a day after school started, for the record ), I received a second pair of shoes. Given my treatment by the sketcher folks, I didn't feel the need to return them.
    Heck, Target must be using the same system then, even though their customer support is very nice for a change! I've ordered two Nintendo DSis. First I ordered just the console. I then noticed that a bundle of console and accessories cost less than getting the accessories separately at the store, so I ordered the bundle and canceled the original console order. I've got a free DSi out of that deal -- there was no way in their system to do a return, and I was never charged for it. So I can't complain about that at all. Another kid got it for the holidays, so all is well in the karmaverse :)
  • hoodaticus 2012-01-26 15:14
    If they did it right it would be elegant. The way they're doing it is a wtf. HTML already is XML, only much more efficient than what they're doing.

    XML + XSLT => HTML ~ MODEL + VIEWMODEL => VIEW
  • hoodaticus 2012-01-26 15:25
    wbrianwhite:
    Berend de Boer:
    I don't get this. This seems to be a very legitimate and neat way of doing things. Band-width saving spitting out of XML, save server cpu by distributing rendering over all clients, it loads fast?

    Really, in many years this is the first article where I have to say nothing to see here.


    So you have a lot of people who design HTML layouts at your company who are also expert at XSLT? Using this pattern requires middling-to-good programmers just to do basic layout changes. And then you get awesome problems like NaN not being tested correctly in the xsl causing your home page not to render.
    I'm quite experienced with XSLT, and I have to say you are absolutely correct. I can make ten somewhat complex Silverlight sites in XAML and C# in the time it takes me to distill a similar page into an XSLT stylesheet.

    On second thought, make that 50. However, if I had pre-defined transformation libraries in XSLT, I could do a lot more. See also: The Ninth Circle; The First Rule of Holes.
  • Nagesh 2012-01-26 15:31
    hoodaticus:
    wbrianwhite:
    Berend de Boer:
    I don't get this. This seems to be a very legitimate and neat way of doing things. Band-width saving spitting out of XML, save server cpu by distributing rendering over all clients, it loads fast?

    Really, in many years this is the first article where I have to say nothing to see here.


    So you have a lot of people who design HTML layouts at your company who are also expert at XSLT? Using this pattern requires middling-to-good programmers just to do basic layout changes. And then you get awesome problems like NaN not being tested correctly in the xsl causing your home page not to render.
    I'm quite experienced with XSLT, and I have to say you are absolutely correct. I can make ten somewhat complex Silverlight sites in XAML and C# in the time it takes me to distill a similar page into an XSLT stylesheet.

    On second thought, make that 50. However, if I had pre-defined transformation libraries in XSLT, I could do a lot more. See also: The Ninth Circle; The First Rule of Holes.


    is silverlight good for any business oportunities?
  • Robert B. 2012-01-26 15:32
    hoodaticus:
    HTML already is XML...


    Eh? Totally valid HTML:

    <html>
    <body>
    <img src="someurl">
    </body>
    </html>

    Let's see you load that up into an XML parser. Tell me the color of the barf.
  • hoodaticus 2012-01-26 15:35
    Good point. I missed the first node. On the other hand, your sample isn't valid HTML either.

    Addendum (2012-01-26 15:41):
    Actually, I just remembered the XML version specifier is optional, so I was right all along. No cookie for you!

    Also, I parse HTML with XMLDOM all the damn time.
  • hoodaticus 2012-01-26 15:37
    Nagesh:
    is silverlight good for any business oportunities?
    Sure. Usually internal shit, but I hear their money is still pinkish off-green like everyone else's. Also, it doubles as WPF experience to an extent.

    Addendum (2012-01-26 15:45):
    Also - Silverlight is ridiculously fast compared to... well... everything. As .NET is Java with the stupid sucked out, so is Silverlight Flash with the Adobe sucked out.
  • Former IE user 2012-01-26 15:37
    Even IE6 supports XSLT. I once had an RSS feed of cartoons scraped from the web. After adding a little XSL it was viewable in the browser. Firefox did have better support, but I managed to make something that worked in both browsers.

    Personally I think it's just as "crazy" as some of the Javascript MVC frameworks out there that uses the web browser to componse the page. A little XSL can sometimes be more readable than that mess.
  • Meep 2012-01-26 15:39
    Kuba:
    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.
    Here's probably why Googlebot doesn't do XSLT: it'd be fairly easy to create a "big" site full of "random" on-the-fly generated content. XSLT would then implement a computation that you want, and would feed the results back to your server in the HTML requests coming from such a crawl. Presto, you get google to do your computations for you, for free.


    Not sure how you could coax Googlebot to send a response to you by XSLT, but supposing, for the sake of argument, that you could: you'd have whatever portion of your code run Googlebot felt like running, when it felt like running it. Somehow that doesn't seem like the best way to get free processing, not when I can create a mostly legal botnet by writing a screensaver and claiming that it's developing a cure for genital warts.

    I suspect that search engines don't transform XSLT because it's a pointless endeavor. If you want to index natural langauge, it's either there in the XML or it's not. Similarly, if you want to index structured-ish data, it's already there in the XML. The results of XSLT are usually *less* useful to a machine.
  • hoodaticus 2012-01-26 15:44
    Former IE user:
    Even IE6 supports XSLT. I once had an RSS feed of cartoons scraped from the web. After adding a little XSL it was viewable in the browser. Firefox did have better support, but I managed to make something that worked in both browsers.

    Personally I think it's just as "crazy" as some of the Javascript MVC frameworks out there that uses the web browser to componse the page. A little XSL can sometimes be more readable than that mess.
    Microsoft's XML parsers used to suck monstrous donkey dick though. I would be scared to do that in IE6.
  • Boog, I Am Your Father! (aka Behold The Return Of Zunesis!)! 2012-01-26 16:02
    Anketam:
    Dave-Sir:
    java.lang.Chris;:
    Mrs. Nagesh:
    "..., ran like a dog, ..."

    Greyhound?

    It's a British expression that describes something which runs more like an asthmatic Dachshund with only two legs than a thoroughbred Greyhound.

    It's a common expression on this side of the pond, as well. However, it's one of those expressions that's not particularly well thought-out. Most dogs I'm familiar with (the healthy ones, at least) run quite fast.

    Another example: Anyone who describes a good night's sleep as "sleeping like a baby" never had one.
    Or my favorite "Sweating like a pig" (pigs are barely capable of producing sweat, they have to wallow in mud to keep cool).
    Or "the bee's knees". The first time I heard that: I'm like: "What the fuck is that shit? Go back to the fucking forties and talk like that, not during my enema!" I swear, my grandpa still thinks the war's on with the Krauts. Funny, because we had sauerkraut when we were finished. I guess even the stench of my own excrement isn't enough to get me hard anymore. Maybe I'll try little boy's next.
  • Martin D 2012-01-26 17:01
    Ralph:
    TheRealAaron:
    Actually it is. You implicitly agree to this any time you visit a website. Maybe most sites don't use your processor to render XSLT but they use it one way or another—HTML rendering, JavaScript execution, CSS box model calculations, etc. If you can't spare the processing power it takes to render a page in a browser, you can't afford to be browsing the web. Honestly, processor power on a typical PC is about as close to free as things get.
    Nope.

    I explicitly don't agree.

    And it isn't because of the "cost" of CPU time. I'm happy to process data (HTML, CSS) on my machine. You do not get to run your executable code on my machine. It's mine not yours. Get it now?
    You're a creepy weirdo.
  • Shutterbug 2012-01-26 17:02
    Lester:
    Ridiculously complex for absolutely no good reason.


    Isn't the the absolute definition of 'Enterprise-y'?

    (Disclaimer: I haven't read all 120-ish comments so don't shout at me if somebody else has already pointed this out!)
  • Cyt 2012-01-26 17:03
    Server side XML has its merits, but I agree this site is DoingItWrong dot com.

    I once built some crappy Apache+Python server system that would deliver test reports (generated by a test engine running on a PC + STB) to the client, who could then view the reports nicely. I found it quite handy to do it this way since the XML schema was already defined and in use before the idea of serving it as HTML to the user came around.

    Heck, I would probably still go for this model.
    And what's with this IE bashing? It worked perfectly well on all browsers, no server-side testing (that said, the HTML was super-simple with little css involved - mainly for colours). (I do remember longing for xslt2 to be supported).

    Bonus info: Excel supports it too - load an XML with an XSLT declaration in the header into Excel and it transforms the lot into HTML and then into a spreadsheet - and yes, we used this too - the managers loved it...

  • Fedaykin 2012-01-26 17:09
    The goals you talk about are good. The problem is that the technologies of the web, once again, totally drop the ball on developing a consistent, developer friendly toolset to accomplish those goals.

    XLS is just part of a long list of these failures:

    HTML/JS is nice for presenting simple data with a simple system. For building an application that must be maintainable and cross platform, it's a nightmare. HTML/JS were built for *presenting data* not for building interactive applications. Don't get me wrong, they are very good at their designed purpose, but are utter failures at the new purpose (app development) we are trying to wedge them into.

    CSS is a nightmare of cross browser compatibility, and is a misguided attempt to combine layout and styling, which are similar but distinct concerns. Add to that it's layout capabilities are severely lacking (where's my flow, divided boxes, border, grid, etc. layouts?) and/or brutal to get correct across multiple browsers and it's a total failure in the layout department.

    Newer web frameworks like Dojo and GWT are commendable attempts to fix all these (and a myriad of other) flaws -- but they still rely on a fundamentally broken foundation (for app development). Has you seen the generated code from GWT?

    This is why we are seeing a resurgence of platform development in the mobile world. iOS and android provide tools that, while still flawed, completely outclass web technologies for the purpose of creating applications -- because they were designed for that purpose.

    We're stuck with the broken foundation in the desktop realm, but in the mobile realm we have a new beginning that has a chance (a slim one unfortunately) of righting the ship for the future.
  • Hans 2012-01-26 17:33
    Aah; Good o'l Fortran IV (66) without the ELSE part. THAT was good times.
  • Ted 2012-01-26 17:34
    geoffrey:
    hobbes:
    I have had the "pleasure" of ordering from Sketchers before. A week and a half prior to my daughter starting second grade at a new school, she was terrified. All she wanted were her "special shoes" ( the bella ballerina shoes, for those keeping score at home ). Figuring a week and a half is more than enough time to get the shoes in, I made the mistake of ordering them from their website ( sketchers ). 10 business days to ship. No other shipping options.

    Once I found that out ( the ording process didn't make that clear until after the bill was paid ), I spent a couple days trying to get a hold of someone, to see if we could expedite that. When I finally did get a hold of someone, they seemed completely uninterested and, frankly, annoyed that I had called. Ultimately, they were unable to do anything for me. So I canceled my order, and ordered from zappos instead. Shoes cost slightly less and were at my door the next day.

    What's funny is I canceled my order with sketchers, got a refund and everything. Then, about a week and a half later ( a day after school started, for the record ), I received a second pair of shoes. Given my treatment by the sketcher folks, I didn't feel the need to return them.


    So you're using perceived mistreatment by a party to justify stealing from them. That speaks wonders to your character.


    Publicly traded corporations steal from people all the time and the law enables them to. They use their money and influence to avoid taxes, manufacturer their product outside of our borders to fuck our economy, and generally not give a fuck about anything but their quarterly earnings.

    Yea, it's all legal. Bought and paid for laws allow for it. So it's not "stealing."

    Not returning the shoes and not pointing out a logistical error on their part isn't illegal, either. It's not "stealing."

    The company is profit driven and only profit driven. The individual is correct in treating them the same way. That is, he has profited an extra pair of shoes.

    The fact you're so fucking naive that you don't realize this speaks wonders to your character.
  • Silverhill 2012-01-26 17:59
    ObiWayneKenobi:
    Oh god it burns. It's like some pages here at my company that display "reports" that are printed out, photographed on a wooden table, OCR scanned, converted into XML, transformed with XSL and output to an ASP.NET label control as a string.
    FTFY.
  • PPH 2012-01-26 18:02
    hoodaticus:
    Former IE user:
    Even IE6 supports XSLT. I once had an RSS feed of cartoons scraped from the web. After adding a little XSL it was viewable in the browser. Firefox did have better support, but I managed to make something that worked in both browsers.

    Personally I think it's just as "crazy" as some of the Javascript MVC frameworks out there that uses the web browser to componse the page. A little XSL can sometimes be more readable than that mess.
    Microsoft's XML parsers used to suck monstrous donkey dick though.

    Now you made me hungry.
  • herby 2012-01-26 18:45
    All this XML, XSL, Java, Python, Perl, and HTML stuff is making me want to go back to ASR33 teletypes with an acoustic coupler and dial-up.

    Of course, I feel that everyone who professes to be a programmer should try using slow teletypes (or punch cards) just to make sure they know how. It should make them realize that not everyone has the mega-huge computer that they do. Oh, and it will humble you pretty quick as well.


    p.s. Been there, done that.
  • the count 2012-01-26 19:57
    0,1,2,3,4,5,6 = 7th
    1,2,3,4,5,6,7 = 7th
    a,b,c,d,e,f,g = 7th

    Did I miss something?
  • Call Me P 2012-01-26 20:55
    This is eerily familiar to me, having implemented a similar system on a smaller scale in the not-so-distant past. When we told our boss that our system would be receiving XML documents from our data sources and producing a unified XML document for export, he immediately demanded that we use XSL. He claimed that was how our organization always handled XML to XML conversions.

    Unfortunately for us, we had multiple source trees and a need for lots of general purpose computation going on between the inputs and outputs. Rather than try to exploit Turing equivalence or something equally mad, we came up with the best strange compromise we could. We would concatenate all the source trees, do all our business logic beforehand, append the results of every general purpose computation we wanted done, and finally pass it through XSL for the output formatting.

    This is just as WTF-worthy as it sounds, I assure you. We are only lucky that we managed to fulfill the requirements demanded of us in a modular enough way we could hope to maintain going forward.
  • Darth Paul 2012-01-26 22:40
    Boog, I Am Your Father! (aka Behold The Return Of Zunesis!)!:
    Or "the bee's knees".


    To be fair, this was probably an amusing pronunciation of "the business".
  • Simon 2012-01-26 23:53
    Chris:
    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.


    Wow do you work for an old company I worked for? We had this exact same setup, for a custom CMS. Not a bad architecture, if you want to transform the output to many different formats (i.e. web, mobiles, JSON, rss, whatever). Except most of these hadnt event been invented at the time.

    I was the only web guy in the place, forced to create the xslt transforms.
  • derpderp 2012-01-27 00:21
    Every person here that thinks XSL is a good idea has clearly never created anything remotely resembling a Web site using XSL. Wanna output some attributes on a tag based on a condition? TOO BAD: THE XSL FILE MUST BE VALID XML. Wanna iterate through a list of invoice items, adding up their subtotals, and then print out a total? TOO BAD: VARIABLES ARE ACTUALLY CONSTANTS. Fuck XSL.
  • x 2012-01-27 01:29
    Ted:
    geoffrey:
    hobbes:
    I have had the "pleasure" of ordering from Sketchers before. A week and a half prior to my daughter starting second grade at a new school, she was terrified. All she wanted were her "special shoes" ( the bella ballerina shoes, for those keeping score at home ). Figuring a week and a half is more than enough time to get the shoes in, I made the mistake of ordering them from their website ( sketchers ). 10 business days to ship. No other shipping options.

    Once I found that out ( the ording process didn't make that clear until after the bill was paid ), I spent a couple days trying to get a hold of someone, to see if we could expedite that. When I finally did get a hold of someone, they seemed completely uninterested and, frankly, annoyed that I had called. Ultimately, they were unable to do anything for me. So I canceled my order, and ordered from zappos instead. Shoes cost slightly less and were at my door the next day.

    What's funny is I canceled my order with sketchers, got a refund and everything. Then, about a week and a half later ( a day after school started, for the record ), I received a second pair of shoes. Given my treatment by the sketcher folks, I didn't feel the need to return them.


    So you're using perceived mistreatment by a party to justify stealing from them. That speaks wonders to your character.


    Publicly traded corporations steal from people all the time and the law enables them to. They use their money and influence to avoid taxes, manufacturer their product outside of our borders to fuck our economy, and generally not give a fuck about anything but their quarterly earnings.

    Yea, it's all legal. Bought and paid for laws allow for it. So it's not "stealing."

    Not returning the shoes and not pointing out a logistical error on their part isn't illegal, either. It's not "stealing."

    The company is profit driven and only profit driven. The individual is correct in treating them the same way. That is, he has profited an extra pair of shoes.

    The fact you're so fucking naive that you don't realize this speaks wonders to your character.


    Looks to me like your dictionary is broken. What you term profit is called a windfall; in your case, it was obtained due to an error of which you are clearly aware. In a court of law, given that you have made no effort to return them, your continued possession of the shoes is most definitely illegal, your own mental gymnastics notwithstanding.

    If you mean to make a moral point, you might try framing it in moral, rather than legal, terms. Because in the latter case, you haven't a leg to stand on.
  • Dathan 2012-01-27 03:21
    derpderp:
    Wanna output some attributes on a tag based on a condition? TOO BAD: THE XSL FILE MUST BE VALID XML.


    Yeah,this sucks. <xsl:if test="blah"><xsl:attribute ... /></xsl:if> would be the way to go. Instead, if you want this behavior, you have to create templates to create the attributes you want unconditionally, and then call them conditionally. In the worst case you have to generate templates for the full Cartesian product of the attributes you want to set conditionally. Fail.

    derpderp:
    Wanna iterate through a list of invoice items, adding up their subtotals, and then print out a total? TOO BAD: VARIABLES ARE ACTUALLY CONSTANTS. Fuck XSL.


    Actually, this is true of any functional-style language. Just use recursion instead.
  • David 2012-01-27 03:39
    AN AWESOME CODER:
    I almost fell for this trolling.

    I am not trolling. XSL is designed to transform from one SGML to another, and it is particularly good at XML-to-HTML transforms. TRWTF is why you would write C# or Java or PHP code to do the transform when there is a custom-designed language for this purpose. So don't knock it just because you find XSL hard. I find Erlang hard but I don't knock it because I know it has a specific purpose which it fulfills extremely well.

    And as I said, if they were writing code to extract the data from the ERP system which then generated the XML, then it would be a different matter, because the pragmatic solution would be to just spit out HTML directly instead of first going to XML.
  • Gilles 2012-01-27 03:55
    verisimilidude:
    PIPA Request: You have posted copyrighted code that (may) belong to someone else. Your DNS records are being removed as well as the DNS records of all sites you link to


    I just pissed my pants ^^
  • L. 2012-01-27 07:13
    geoffrey:
    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.



    geoffrey for president .. the only troll actually delivering reliable quality trolling all the time.
  • PedanticCurmudgeon 2012-01-27 08:41
    the count:
    0,1,2,3,4,5,6 = 7th
    1,2,3,4,5,6,7 = 7th
    a,b,c,d,e,f,g = 7th

    Did I miss something?
    Yes. The quote button.
  • PedanticCurmudgeon 2012-01-27 08:42
    derpderp:
    Every person here that thinks XSL is a good idea has clearly never created anything remotely resembling a Web site using XSL. Wanna output some attributes on a tag based on a condition? TOO BAD: THE XSL FILE MUST BE VALID XML. Wanna iterate through a list of invoice items, adding up their subtotals, and then print out a total? TOO BAD: VARIABLES ARE ACTUALLY CONSTANTS. Fuck XSL.
    tl;dr version: I can't XSL.
  • Boog, I Am Your Father! (aka Behold The Return Of Zunesis!)! 2012-01-27 09:15
    Darth Paul:
    Boog, I Am Your Father! (aka Behold The Return Of Zunesis!)!:
    Or "the bee's knees".


    To be fair, this was probably an amusing pronunciation of "the business".
    Well, he does buy me ice cream afterward, so I guess it is a sort of business.
  • Curious 2012-01-27 09:19
    Mason Wheeler:


    6000 lines is nothing on modern hardware. Heck, the Delphi compiler can chew through that in literally a fraction of a second. Any parser worth the name, for pretty much any language won't even blink at 6KLOC. (Assuming, of course, that you're not using a broken language such as C++ where parsing itself can be a Turing-complete task and so can take an arbitrary amount of time even on small inputs.)

    Is that including, or not including, the preprocessor?
  • Jim Blog 2012-01-27 09:55
    Did something like this myself, about 13 or 14 years ago. Well, apart from the fact I was using Cocoon to do the XSLT translation on the server as browser support for XSLT in the late 1990s was a bit more limited. As I recall it ran dog slow, but maybe average computer performance has now increased to the point where doing this is actually practical.

    Oh yeah, and also except for the fact that I was writing a small index of learning materials for a mostly academic audience, and the XML was our data-layer (had to jump through too many IS hoops to get a "proper" database installed), and not a major retail website like skechers.com!
  • test 2012-01-27 09:59
    Niko:
    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).


    Quoted for truth. Personally, I don't find it offending, the sketchers site loads pretty quickly, with most page being less than 5kb ... It does suck for SEO though.
  • Naguissa 2012-01-27 10:44
    I use time to time Midori as web browser.

    For any reason, I can only view the pure XML, it's not parsed. Whe you open the site the only you think is.... WTF?
  • lmm 2012-01-27 10:50
    David:
    AN AWESOME CODER:
    I almost fell for this trolling.

    I am not trolling. XSL is designed to transform from one SGML to another, and it is particularly good at XML-to-HTML transforms. TRWTF is why you would write C# or Java or PHP code to do the transform when there is a custom-designed language for this purpose. So don't knock it just because you find XSL hard.


    Only if the custom-designed language were any good for that purpose. It's not. If doing those transforms in XSL is harder than doing it in C# or Java or PHP - and it is - then it doesn't matter that XSL was designed for it. It just means XSL is useless.
  • wbrianwhite 2012-01-27 10:55
    Sooo... I was thinking about this last night. I think what would have really sent this over the top is if the XML that they started with was just an ADO recordset persisted as XML format. Then I would have really tipped my hats to the geniuses involved.
  • wbrianwhite 2012-01-27 10:59
    lmm:
    David:
    AN AWESOME CODER:
    I almost fell for this trolling.

    I am not trolling. XSL is designed to transform from one SGML to another, and it is particularly good at XML-to-HTML transforms. TRWTF is why you would write C# or Java or PHP code to do the transform when there is a custom-designed language for this purpose. So don't knock it just because you find XSL hard.


    Only if the custom-designed language were any good for that purpose. It's not. If doing those transforms in XSL is harder than doing it in C# or Java or PHP - and it is - then it doesn't matter that XSL was designed for it. It just means XSL is useless.


    We use a lot of XML->XSL->XML transforms in our shop. We have common requests come in in a single format, and then get transformed to the supported dialect for the outbound connector they're going to. When we were building up that tier, it was the state of the art practice. C#/Linq may be as fast for the transforms, but didn't exist as technologies at the time. Java and PHP are not anywhere near as fast. There are times when performance speed trumps developer time, even if they're not the majority of times.
  • YF 2012-01-27 11:34
    Lord Almighty... this is freaking insane.
    It is the utmost misuse of technology... put all buzzwords in a blender and you get this.

    But the ol' plain bad coding is still there, in all it's glory:

    var f=d.getUTCMonth()+1;
    if(f<10)f="0"+f;
    var g=d.getUTCDate();
    if(g<10)g="0"+g;
    e=d.getUTCFullYear();
    var h=d.getUTCHours();
    if(h<10)h="0"+h;
    var j=d.getUTCMinutes();
    if(j<10)j="0"+j;
    var m=d.getUTCSeconds();
    if(m<10)m="0"+m;
    d=d.getUTCMilliseconds();
    if(d<100)d="0"+d;
    if(d<10)d="0"+d;
    return'"'+e+"-"+f+"-"+g+"T"+h+":"+j+":"+m+"."+d+'Z"'


    Disguise it with XML, XSLT, whatever... still the same crap.
  • wbrianwhite 2012-01-27 11:41
    Fedaykin:
    The goals you talk about are good. The problem is that the technologies of the web, once again, totally drop the ball on developing a consistent, developer friendly toolset to accomplish those goals.

    XLS is just part of a long list of these failures:

    HTML/JS is nice for presenting simple data with a simple system. For building an application that must be maintainable and cross platform, it's a nightmare. HTML/JS were built for *presenting data* not for building interactive applications. Don't get me wrong, they are very good at their designed purpose, but are utter failures at the new purpose (app development) we are trying to wedge them into.

    CSS is a nightmare of cross browser compatibility, and is a misguided attempt to combine layout and styling, which are similar but distinct concerns. Add to that it's layout capabilities are severely lacking (where's my flow, divided boxes, border, grid, etc. layouts?) and/or brutal to get correct across multiple browsers and it's a total failure in the layout department.

    Newer web frameworks like Dojo and GWT are commendable attempts to fix all these (and a myriad of other) flaws -- but they still rely on a fundamentally broken foundation (for app development). Has you seen the generated code from GWT?

    This is why we are seeing a resurgence of platform development in the mobile world. iOS and android provide tools that, while still flawed, completely outclass web technologies for the purpose of creating applications -- because they were designed for that purpose.

    We're stuck with the broken foundation in the desktop realm, but in the mobile realm we have a new beginning that has a chance (a slim one unfortunately) of righting the ship for the future.


    This is why HTML 5 has come out. It builds things like input type="email" and slider controls right into HTML. It has new semantic tags for Article, Section, etc. It has enhanced local storage. It builds a freakin' sql database into the browser for goodness sake. It's also why you want to use a JS framework, like JQuery or Prototype to smooth over browser differences. Combine HTML 5 and JQuery and you're golden.

    HTML 5 mobile apps will eventually overshadow native apps for any shop that isn't a mobile pure play shop. Why? You write it once, it runs on iOS, Android, Kindle, IE, Firefox, Chrome, Safari, etc. and can easily have the same look and feel as a native mobile app. Versus writing 6 different native apps. And maintaining 6 different native apps. And managing the update push process. Yuck.
  • BCD 2012-01-27 12:30
    The real reason xml-based xslt tranformed site design never took is that google can't crawl xml, only html. Or at least circa 2006 they couldn't. Learned that one the fun way.
  • Ben 2012-01-27 12:45
    The idea of a website in XML to be transformed via XSLT is neither new nor special; it's at least a decade old. It was touted as a way to address different browser platforms (back when the web on a phone meant WML); however, when I had seen the technique used, usually the transformation was done server-side rather than client-side.
  • M242 2012-01-27 13:30
    Ha! This is great-- I've been mentioned on TheDailyWTF, that's going to the very top of my resume. I'm the manager of the web team at Skechers, and we've all been having a great time reading the thread and the comments. Thank you, everyone, this is a great way to start a Friday. I would say that both the "wtf this is horrible!" and "no, this is great!" sides of the argument have great, valid points.

    I can't give extremely detailed explanations of our code for obvious reasons, but here's a quick FAQ.

    WTF are you insane?!? XSLT is (maintenance nightmare|slow|hacky|terrible language)!

    You're right! Writing the XSLT took a good chunk of time, and we had to do a lot of workarounds to get the resulting output the way we wanted it to look. Whenever the XSLT wasn't well-formed, trying to debug it was a mess of biblical proportions. Luckily, maintenance of the XSLT isn't that bad; both the XSLT and the structure of the XML rarely change.

    But here's the great thing about XSLT-- it's cacheable on your browser. Instead of browsing from page to page to page, each time getting 25k+ of html, we can frontload a lot of that by having you download the XSLT. Once you've downloaded the file once, you have the layout for the entire site already cached, and the next page you go to is 2k of XML.

    ...but (JQuery Templates|Hogan|Backbone|etc)!

    You're absolutely right; unfortunately none of those were really mature enough at the time we started developing the site. My original thought was-- your desktop machine, and very quickly your phone, have just as much CPU cycles available as a commodity server. Why not shift as many cycles to the client as we can while still making it a relatively fast experience?

    ...but the browser support sucks!

    It's funny, IE7 and IE8 actually have better support for XSLT transformations than Firefox does. You want to see one of the crappiest browser bugs in the world? https://bugzilla.mozilla.org/show_bug.cgi?id=98168 was opened in _2001_. <xsl:text disable-output-escaping="yes"> doesn't actually work in Firefox. WTF?!? Anyways, the reason we run the transform on the server (trivial) for IE users is because IE9 actually broke their XML/XSLT transform engine, but only when you're visiting the page from a 304 redirect. That wasn't a fun bug to find.

    WHY, man, WHY?!? This is just insane!

    Is it any more insane than hunting through Struts code, or JSF, etc etc? Now, both our front-end CSS/Javascript developers, and back-end Java (now Scala) coders understand Xpath now, so we don't run into the "I don't want to touch that Velocity template" problem.

    How'd you come up with this idea, anyways?

    We were playing around with the RESTEasy framework. One of the great things about RESTEasy is that it allows you, via JAXB, to marshal and unmarshal POJOs to XML/JSON extremely easily; like, one @Produces("application/xml") annotation in your POJO and that's all you have to do. Well, hell, we have REST methods for obtaining catalog information, why can't we just output an entire page the same way?

    Similarly, I saw a pseudo-trolling comment about the enterprisey ERP system returning XML. That's actually very close! We take the XML output from our implementation of Endeca (essentially Solr on steroids) and just slam it to the browser. The amount of server-side code to run the browsing experience on the site (a pseudo controller, if you want to talk MVC pattern) is, basically, one class of about 100 LOC, most of which is web service calls.

    There was some comment about the Wow Armoury earlier on. I used to work for Vivendi, when we owned Blizzard (the plot thickens...). So while I didn't write the Armoury, I did try to keep up with the web technologies that they were using. I thought it was a brilliant idea, but that they didn't go far enough. Far-expires, plus cacheable view layer, plus very small subsequent http payloads, what's not to love about that?

    Sorry. This is still WTF.

    Given today's technology and how much Javascript templates have matured, you're probably right. As with any project, we've seen our share of development pain, and there's a lot of spaghetti XSLT I'm sure. It works really well for us, though, and turned what used to be an extremely slow JSF-based mess into a pretty fast browsing experience.

    What we're looking at now are technologies like Hogan, CouchDB, Bootstrap, Backbone, and the Play Framework (specifically the 2.0 beta). We've adopted Scala for all new code, and there are some really exciting technologies available now that really weren't when we created the site, so yeah, maybe the next version of skechers.com is just one very small HTML template that gets served up no matter which page you go to.

    Thanks again, everyone, this is great. It's hilarious to be mentioned on the site.
  • Jay 2012-01-27 14:04
    Sigh. All these posters with the silly idea that the point of a software development project is to produce working code that satisfies some practical need and which can be understood and maintained by future programmers. But of course the REAL purpose of software development projects is to provide entertainment to the developers, and the best way to do that is to use the most complex and obscure technologies that you can find.
  • Is that a suppository up my ass or are you just happy to see me? 2012-01-27 14:26
    M242:
    Ha! This is great-- I've been mentioned on TheDailyWTF, that's going to the very top of my resume. I'm the manager of the web team at Skechers, and we've all been having a great time reading the thread and the comments. Thank you, everyone, this is a great way to start a Friday. I would say that both the "wtf this is horrible!" and "no, this is great!" sides of the argument have great, valid points...

    Thanks again, everyone, this is great. It's hilarious to be mentioned on the site.
    And I, in turn, commend you on your grace in accepting this badge of "honor"!

    I (have to) use XSL all the time, mostly for XML->XML purposes, sometimes XML->Flat file, and while I hate coding in it, it does offer the benefit of allowing us the ability to patch changes to our QA/Prod environments with great ease. Just replace the xsl file on the server and you're done! Couldn't be easier!

    As for Sketchers.com, I thought this was the whole idea behind XSLT: translating XML content to HTML presentation. Seems pretty straight-forward.

    Whatevs,
    Congratulations, man!
  • hoodaticus 2012-01-27 14:54
    Call Me P:
    This is eerily familiar to me, having implemented a similar system on a smaller scale in the not-so-distant past. When we told our boss that our system would be receiving XML documents from our data sources and producing a unified XML document for export, he immediately demanded that we use XSL. He claimed that was how our organization always handled XML to XML conversions.

    Unfortunately for us, we had multiple source trees and a need for lots of general purpose computation going on between the inputs and outputs. Rather than try to exploit Turing equivalence or something equally mad, we came up with the best strange compromise we could. We would concatenate all the source trees, do all our business logic beforehand, append the results of every general purpose computation we wanted done, and finally pass it through XSL for the output formatting.

    This is just as WTF-worthy as it sounds, I assure you. We are only lucky that we managed to fulfill the requirements demanded of us in a modular enough way we could hope to maintain going forward.
    TRWTF is that in XML land, that is not a WTF.
  • hoodaticus 2012-01-27 15:02
    The Skechers dev apparently missed the extremely laughable conf node...
  • David 2012-01-28 07:07
    M242:
    Similarly, I saw a pseudo-trolling comment about the enterprisey ERP system returning XML. That's actually very close! We take the XML output from our implementation of Endeca (essentially Solr on steroids) and just slam it to the browser. The amount of server-side code to run the browsing experience on the site (a pseudo controller, if you want to talk MVC pattern) is, basically, one class of about 100 LOC, most of which is web service calls.


    Ha! Score! I was right... kudos, M242 - I would have done exactly the same. Yeah XSL is not as easy to use as it should be, yeah there are compatibility issues, but it's the obvious thing that comes to mind when I have XML and I want HTML.
  • anonymouse 2012-01-28 07:40
    DWalker:
    Xenious:
    Pony:
    Not sixth, seventh, dude.


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


    As opposed to tighter?


    This comment thread just keeps getting better and better :) Thanks! you are all going into my quote file.
  • Randy Snicker 2012-01-28 10:07
    M242:
    Why not shift as many cycles to the client as we can while still making it a relatively fast experience?

    Dear web designers/developers, this is why people hate you.
    Instead of being able to use your CPU cycles for something productive or at least pleasant, we "get" to use them for this. Add a couple of advertisers that have the same mindset and you find yourself having paid for a top-of-the-line computer with the effective processing power of a 133MHz Pentium.
  • Theman 2012-01-28 15:28
    I tried it in Chrome, it renders almost instantly. If browser technology is up to it, I really don't see this as a WTF. It would have been 10 years ago but it seems to have matured significantly.
  • method1 2012-01-28 17:25
    Dennis:
    No one cares about your whining.
    Except you, Dennis...
  • method1 2012-01-28 17:47
    Paul Neumann:
    Perhaps you are new to the interwebs? Here is a guide you should find most useful: http://goatse.info

    FTFY
  • Soulweaver 2012-01-29 00:21
    Looks like they aren't very NoScript friendly either.

    http://img844.imageshack.us/img844/2360/skechers.jpg
  • Rupert 2012-01-29 07:55

    and turned what used to be an extremely slow JSF-based mess


    Just to be clear, JSF can be really fast and allows for very clean / maintainable code. Yes, I've seen people f*cking up badly with it, but as this is TDWTF you probably know people can f*ck up with basically everything.

    Just stay away from the old JSF 1.x, use JSF 2.x, follow some of the best practices and you'll be fine with JSF ;)
  • Josh 2012-01-29 09:18
    > We've adopted Scala for all new code

    I'm astounded that you'd go from this giant turd sandwich to something as nice as Scala.
  • Arkh 2012-01-29 12:05
    I clicked on the link to sketchers.com.
    I got this: http://tof.canardpc.com/view/86c6ab8b-9002-4267-b12d-3c17b715578b.jpg
    I never thought I would see something worse than a flash website when using noscript.
  • Robert Rossney 2012-01-29 15:05
    I dunno, kids. Maybe I just learned to identify with my torturers. But I've been using XSLT for client-side transformation since 1999. (Those people who keep saying XSLT doesn't work in IE: what the hell are you talking about? XSLT worked in IE back when it was still a W3C working draft.)

    It's hard to learn to think the way XSLT requires you to think. You'll come to the language with crazy notions like that variables can vary, for instance, or that looping is a first-class programming technique. In XSLT, variables get set once and never change, and loops are a last resort. Until you understand why these things are true, you'll sound like a lot of people in this thread.

    But once you start identifying with your torturers, XSLT is pretty hard to argue with. A platform-independent data transform language that's side-effect free? That's enormously powerful. I've built applications with enormous amounts of transformation logic - literally many hundreds of XSLT templates for a single document. I've gone back to those applications after not looking at the code for two years to implement new features. The new features come up disturbingly quickly, and my changes never introduce bugs into existing code. I've never come to an old project and thought, "Oh, God, I wish I hadn't used XSLT here." It's more like "Thank God I can fix this in the XSLT, so that I don't have to figure out what's going on in the C#/Java/JavaScript/VB code I wrote six years ago." (My C# programming style has changed enormously over the last decade. My XSLT style has changed very slightly.)

    Yes, it sucks to work with a language that can't do date arithmetic, use regular expressions, or even convert strings to upper case. (You can convert a string to upper case in XSLT, if you use a fantastically stupid hack.) Yes, it's a little dumb that XSLT is XML (until you start using XSLT to generate XSLT; then it makes a little more sense.) Yes, it's mind-bogglingly stupid that sometimes you have to use recursion to iterate over lists. Yes, using the combination of
    key()
    and
    <xsl:key>
    to implement maps is just idiotic. Do not get me started on Muenchian grouping.

    It doesn't matter. XSLT solves a problem that really has no better solution. You can avoid the problem entirely in a lot of ways - never representing your data as XML and using JSON and JQuery on the client, for instance - but in a lot of contexts it's absolutely the right tool for the job.

    No, the true WTF in the skechers.com example is this horrible antipattern:

    <prop value='some_value' strValue='some_other_value' key='name'/>


    One of the primary reasons to use XML in the first place is because it gives you simple and reliable way not only of transporting data but of validating that the data you're getting is right. Using this antipattern throws XML Schema out the window. I suppose these guys thought they had a good reason for this - "We control both endpoints, so we'll never need to validate our messages." I've thought that. I've almost always been proven wrong, and I bet these guys were too.
  • New_Fan 2012-01-29 17:48
    @m242: Massive props + kudos. Next pair of sneakers (well, trainers, I'm British) I'm definitely buying Skechers.
  • Fg 2012-01-29 22:17
    Despicable technology. I'd not be proud of perpetuating this trash.
  • jsno 2012-01-30 01:53
    Soulweaver:
    Looks like they aren't very NoScript friendly either.

    http://img844.imageshack.us/img844/2360/skechers.jpg


    That isn't much different from what I get from all of Gawker Media's sites with NoScript.
  • TR 2012-01-30 05:41
    The idea of generating HTML through XML-XSLT templates doesn't sound as a WTF to me.
    I used to work on a PHP app that the same XML-XSLT generation of HTML code. We used the XSLT engine Sablotron as a PHP extension to perform the generation.
    The difference was that the XSLT transformation was performed on the server (and only the result was sent to the client).
    At the time (2003) no mature frameworks had emerged yet and it was the best we could find to implement a MVC-like presentation/data/logic separation.
  • MrBester 2012-01-30 09:58
    Prior art: http://www.aceflex.com/
    Same shit, just from an established company.
    With one version you can get this, with a later one you can get this

    Captcha: facilisi. The facilisi to take an interesting proof-of-concept idea and screw thousands out of clueless "we need a website to sell our stuff" store owners since before the turn of the millennium...
  • Jay 2012-01-30 14:06
    Robert Rossney:
    I dunno, kids. Maybe I just learned to identify with my torturers. But I've been using XSLT for client-side transformation since 1999. (Those people who keep saying XSLT doesn't work in IE: what the hell are you talking about? XSLT worked in IE back when it was still a W3C working draft.) ...


    I want to do an experiment. Tell the employees at some company that they must write all future technical documentation in Pig Latin, or that we are removing all the desks and chairs and employees must work while lying on the floor, or that the water cooler is being replaced with a pig urine dispenser. I theorize that within six months some number of employees will be prepared to argue forcefully that this is the only sensible way to do business.

    I bet I could get a government grant for this experiment.
  • hoodaticus 2012-01-30 16:34
    Robert Rossney:
    I dunno, kids. Maybe I just learned to identify with my torturers. But I've been using XSLT for client-side transformation since 1999. (Those people who keep saying XSLT doesn't work in IE: what the hell are you talking about? XSLT worked in IE back when it was still a W3C working draft.)

    It's hard to learn to think the way XSLT requires you to think. You'll come to the language with crazy notions like that variables can vary, for instance, or that looping is a first-class programming technique. In XSLT, variables get set once and never change, and loops are a last resort. Until you understand why these things are true, you'll sound like a lot of people in this thread.

    But once you start identifying with your torturers, XSLT is pretty hard to argue with. A platform-independent data transform language that's side-effect free? That's enormously powerful. I've built applications with enormous amounts of transformation logic - literally many hundreds of XSLT templates for a single document. I've gone back to those applications after not looking at the code for two years to implement new features. The new features come up disturbingly quickly, and my changes never introduce bugs into existing code. I've never come to an old project and thought, "Oh, God, I wish I hadn't used XSLT here." It's more like "Thank God I can fix this in the XSLT, so that I don't have to figure out what's going on in the C#/Java/JavaScript/VB code I wrote six years ago." (My C# programming style has changed enormously over the last decade. My XSLT style has changed very slightly.)

    Yes, it sucks to work with a language that can't do date arithmetic, use regular expressions, or even convert strings to upper case. (You can convert a string to upper case in XSLT, if you use a fantastically stupid hack.) Yes, it's a little dumb that XSLT is XML (until you start using XSLT to generate XSLT; then it makes a little more sense.) Yes, it's mind-bogglingly stupid that sometimes you have to use recursion to iterate over lists. Yes, using the combination of
    key()
    and
    <xsl:key>
    to implement maps is just idiotic. Do not get me started on Muenchian grouping.

    It doesn't matter. XSLT solves a problem that really has no better solution. You can avoid the problem entirely in a lot of ways - never representing your data as XML and using JSON and JQuery on the client, for instance - but in a lot of contexts it's absolutely the right tool for the job.

    No, the true WTF in the skechers.com example is this horrible antipattern:

    <prop value='some_value' strValue='some_other_value' key='name'/>


    One of the primary reasons to use XML in the first place is because it gives you simple and reliable way not only of transporting data but of validating that the data you're getting is right. Using this antipattern throws XML Schema out the window. I suppose these guys thought they had a good reason for this - "We control both endpoints, so we'll never need to validate our messages." I've thought that. I've almost always been proven wrong, and I bet these guys were too.


    XSLT doesn't need defending, but as I already pointed out, with the specific example of the conf node - these guys are doing it wrong. Also, it makes a shitty framework for webdev. A development suite that compiled into xslt would be much less of a wtf.
  • nowayman 2012-02-01 14:47
    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


    My company does the exact same thing, it's been that way since 2001. XSL 2.0 does make it easier, and there are a lot of neat tricks you can do with it. (http://incrementaldevelopment.com/xsltrick/) Our data layer returns an XSL resultset, so it seemed logical to use XSLT to return HTML. Of course, we did ours server side instead of client side. Might have gone client side if our site was a high load application. It's not.

    That said, it's 2012 and 11 years is a long time to be using such a verbose template system. You have to remember, 2001 was when XML was the 'in' thing and you had to have XML to be cool. Now it's JSON or some other micro-format. In any case, we designed it so that our customers could modify it with relative ease. However, nobody in the world knows XSLT(, or wants to learn it) anymore.
  • HP LaserJet 2000 2012-02-01 21:56
    "But here's the great thing about XSLT-- it's cacheable on your browser.... Once you've downloaded the file once, you have the layout for the entire site already cached, and the next page you go to is 2k of XML."

    Am I the only one to call bullsh!t on this idea? The "next page" requires high-res images of each product plus real-time FB updates showing us the losers that 'like' the website. Surely those will be the bottleneck, not the HTML rendering?

    We don't all live right next to your server, you know. Some of us are nearly a thousand ms and > 15 hops away.
  • JS 2012-02-02 01:52
    M242: Why not shift as many cycles to the client as we can while still making it a relatively fast experience?

    Relatively fast for an average machine these days equals slow on my current machine. Just because you've got an extra core available to run rendering code on, doesn't mean everyone has one. If I had an extra core, I'd run something useful on it.
  • eMBee 2012-02-02 12:42
    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).


    huh? i've hired a university student who was only familiar with java. he figured out xslt within a week or two. if you hire people who are not prepared to learn something new then you are doing it wrong.

    greetings, eMBee.
  • got you covered 2012-02-02 13:13
    Shutterbug:
    Lester:
    Ridiculously complex for absolutely no good reason.


    Isn't the the absolute definition of 'Enterprise-y'?

    (Disclaimer: I haven't read all 120-ish comments so don't shout at me if somebody else has already pointed this out!)

    I have read them and I can tell you: don't worry, you are safe.

    (Disclaimer: I haven't yet read all the comments after that one, so don't shout at me if somebody else has already pointed this out!)
  • got you covered 2012-02-02 13:32
    derpderp:
    Every person here that thinks XSL is a good idea has clearly never created anything remotely resembling a Web site using XSL. Wanna output some attributes on a tag based on a condition? TOO BAD: THE XSL FILE MUST BE VALID XML. Wanna iterate through a list of invoice items, adding up their subtotals, and then print out a total? TOO BAD: VARIABLES ARE ACTUALLY CONSTANTS. Fuck XSL.

    i am not really a fan of xsl either, but it is not as bad as you make it out.

    try xsl:attribute ( http://www.w3schools.com/xsl/el_attribute.asp (it's klunky, but it can be done)
    and sum() ( http://www.w3schools.com/xpath/xpath_functions.asp )

    greetings, eMBee.
  • Sole Purpose of Visit 2012-02-02 16:09
    Four pages, and people are still defending this monstrous insanity?

    The world is going to Hell in a hand-basket.

    Look, by all means, use some sort of functional transform/projection between XML and HTML. Try to avoid injecting, you know, state along the way.

    But once you've got that sussed, all you have to do is to deal with other possible inputs (a moving target in the Enterprisey world).

    To do that, you are not going to want to touch XSLT. You're going to want a proper AST (I'll accept the DOM as a substitute), and you're going to want an actual goddamn programmer.

    And any fool who claims that "it doesn't matter, because clients these days have multi-core machines that can do all the work for us" is ... um ... actually, it doesn't really matter what I think of them, because their clients will answer on my behalf.

    If they depend on this sort of dreck to keep their business running, then they will very soon (and, being clueless, without warning) realise that their business is no longer running.

    Does this remind anybody else of the Mumps wars on this site a couple of years ago?
  • fred 2012-02-05 21:18
    I tried to view http://www.skechers.com/ with Firefox 7 and it still doesn't display correctly (there's a chunk of JS code sitting in place of where the video's supposed to be.
    Oh well, IE8 and Chrome 16 both seemed to render the website correctly though. Maybe Firefox was treated in the same manner as the usual developers treated IE.
  • MS 2012-02-06 10:41
    Well about 10 years ago "we" did the same thing - but the rendering happened deploy-time for static content and server-side for dynamic stuff. Client always got HTML and JS.


    Main point here... thats a long while ago... today just go GWT, Vaadin or something like that

    kkthxbye
  • Mark 2012-02-07 16:13
    All websites should be built this way. Since I learned the way of the XSLT ninja my development time has fallen through the floor and code quality is way higher (and we get draconian error handling for free, which is a huge omission from HTML).

    This is only a WTF for web monkeys who are too stupid to learn proper coding techniques.
  • Stupid User 2012-02-08 11:05
    Considering that my bandwith is crappier than my CPU, spending a few cycles to save on bandwidth sounds like a pretty sweet deal to me.
  • J.B. 2012-02-09 10:30
    Everyone seems to be missing the REAL WTF:

    Your twelve-page résumé could land you a job anywhere


    Twelve page resumes go to the bottom of my hiring pile. 2 page resumes float to the top. While I will eventually hire on skill demonstrated during an interview, the quality of your resume says a lot about you. Usually it means, "terrible communication skills; can't code their way out of a pickle bucket."

    Two pagers, please. Three in a pinch. :-)
  • M.S. 2012-02-10 05:38
    somehow this seems familiar. I did something exactly like this on a project. The reason was that the project organization guy wanted to have the code based on XSLT templates, which could be reused. However putting the javascript code in (it was an Ajax framework to be more specific) was a major show stopper for a quick progress.
  • krez 2012-02-11 05:59
    I just get "false". Yet another website that insists I enable JavaScript to look at pictures of sneakers. Harrumph.
  • jmo 2012-02-13 19:37
    Actually, I found your site through accidental curiosity (my daughter was looking at it and I peeked at the source...whoa - they're sending XML? XSLT? for SHOES? wtf?). Then I found the WTF article.

    Your point exploiting the browser and caching is actually quite relevant:

    here's the great thing about XSLT-- it's cacheable on your browser. Instead of browsing from page to page to page, each time getting 25k+ of html, we can frontload a lot of that by having you download the XSLT. Once you've downloaded the file once, you have the layout for the entire site already cached, and the next page you go to is 2k of XML.

    I'd say your approach is innovative in positive way. Clearly WTF because it's unexpected, not because it's snafu. Appreciate your feedback on this article. I also work on a retail ecommerce site and I often cry when I see what is sent to the client, especially since we're usually seeing it when a UX test fails...
  • TheRealPinkyAndTheBrainFan187 2012-02-14 16:24
    M242:
    Ha! This is great-- I've been mentioned on TheDailyWTF, that's going to the very top of my resume. I'm the manager of the web team at Skechers, and we've all been having a great time reading the thread and the comments. Thank you, everyone, this is a great way to start a Friday. I would say that both the "wtf this is horrible!" and "no, this is great!" sides of the argument have great, valid points.


    I browse with NoScript on Firefox. When I go to skechers.com I see one word, all alone at the top left of my browser window: false

    Since I started browsing with NoScript installed I've noticed more and more instances of people failing to "fail beautiful" in the absence of Javascript/Flash, but this is the most egregious example I've yet come across! Congratulations.

    Now you say: "Ah, but you're an outlier, most people have javascript turned on"
    So I say: "Ah, but I'm a potential customer".


  • milo 2012-02-20 15:30
    XML is not a technology, it's a syntax.
  • David Walker 2012-09-04 01:01
    Obviously insane. Couldn't possibly be a useful approach. And I can prove it, too. Just visit their site and you'll see how hopelessly ...

    Whoah! Speed! Responsiveness!

    This may be the fastest site I've visited this month. My only question now is why no-one else is doing this.