• giony (unregistered) in reply to Slartibartfast

    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.

  • (cs) in reply to Slartibartfast
    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.
  • (cs) in reply to Berend de Boer
    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 (unregistered)

    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?

  • (cs) in reply to Dave-Sir
    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).

  • (cs) in reply to hobbes
    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 :)
  • (cs)

    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

  • (cs) in reply to wbrianwhite
    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.

  • (cs) in reply to hoodaticus
    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. (unregistered) in reply to hoodaticus
    hoodaticus:
    HTML already is XML...

    Eh? Totally valid HTML:

    <html> <body> [image] </body> </html>

    Let's see you load that up into an XML parser. Tell me the color of the barf.

  • (cs) in reply to Robert B.

    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.

  • (cs) in reply to Nagesh
    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 (unregistered) in reply to Slartibartfast

    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 (unregistered) in reply to Kuba
    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.

  • (cs) in reply to Former IE user
    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!)! (unregistered) in reply to Anketam
    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 (unregistered) in reply to Ralph
    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 (unregistered) in reply to Lester
    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 (unregistered)

    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 (unregistered) in reply to Slartibartfast

    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 (unregistered) in reply to java.lang.Chris;

    Aah; Good o'l Fortran IV (66) without the ELSE part. THAT was good times.

  • Ted (unregistered) in reply to geoffrey
    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.

  • (cs) in reply to ObiWayneKenobi
    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 (unregistered) in reply to hoodaticus
    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.

  • (cs)

    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 (unregistered) in reply to Jan

    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 (unregistered)

    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 (unregistered) in reply to Boog, I Am Your Father! (aka Behold The Return Of Zunesis!)!
    Boog:
    Or "the bee's knees".

    To be fair, this was probably an amusing pronunciation of "the business".

  • Simon (unregistered) in reply to Chris
    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 (unregistered)

    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 (unregistered) in reply to Ted
    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 (unregistered) in reply to derpderp
    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 (unregistered) in reply to AN AWESOME CODER
    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 (unregistered) in reply to verisimilidude
    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. (unregistered) in reply to geoffrey
    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.

  • (cs) in reply to the count
    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.

  • (cs) in reply to derpderp
    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!)! (unregistered) in reply to Darth Paul
    Darth Paul:
    Boog:
    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 (unregistered) in reply to Mason Wheeler
    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 (unregistered)

    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 (unregistered) in reply to Niko
    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 (unregistered)

    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 (unregistered) in reply to David
    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.

  • (cs)

    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.

  • (cs) in reply to lmm
    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 (unregistered)

    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.

  • (cs) in reply to Fedaykin
    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 (unregistered) in reply to oppeto

    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 (unregistered)

    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 (unregistered)

    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.

Leave a comment on “Sketchy Skechers.com”

Log In or post as a guest

Replying to comment #:

« Return to Article