- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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.
Admin
Admin
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.
Admin
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?
Admin
Admin
Admin
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
Admin
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.
Admin
is silverlight good for any business oportunities?
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
Admin
Admin
Admin
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!)
Admin
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...
Admin
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.
Admin
Aah; Good o'l Fortran IV (66) without the ELSE part. THAT was good times.
Admin
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.
Admin
Admin
Admin
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.
Admin
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?
Admin
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.
Admin
To be fair, this was probably an amusing pronunciation of "the business".
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Actually, this is true of any functional-style language. Just use recursion instead.
Admin
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.
Admin
I just pissed my pants ^^
Admin
geoffrey for president .. the only troll actually delivering reliable quality trolling all the time.
Admin
Admin
Admin
Admin
Admin
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!
Admin
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.
Admin
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?
Admin
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.
Admin
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.
Admin
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.
Admin
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:
Disguise it with XML, XSLT, whatever... still the same crap.
Admin
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.
Admin
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.
Admin
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.
Admin
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.