- 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
Posting comments before the article goes live!? Wha!? How?!
Really, the only benefit of following @thedailywtf.
Admin
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
Admin
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
Admin
This is sketchy at best
Admin
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.
Admin
Fantastic, I even learned a new word today!
Admin
sixth!
captcha: Penis.
Admin
Not sixth, seventh, dude.
Admin
Fuck you. It is zero based. Get back on you vb script, looser.
Admin
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)
Admin
I'm reasonably certain that this constitutes grounds for a boycott.
Admin
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.
Admin
Im fairly sure that the world of Warcraft armory does something similar?
Admin
My mistake, perhaps it was an older version but i distinctly remember being told it did this.
Admin
Ahhhh! My eyes! The goggles, they do nothing!!!
Admin
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...
Admin
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...
Admin
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.
Admin
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).
Admin
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.
Admin
Admin
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.
Admin
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.
Admin
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.
Admin
TRWTF is that the XML in the first file isn't even valid! They have no business putting the .xml extension on.
Admin
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...
Admin
Replace "only works on Firefox" with "works in every major browser besides IE". This isn't 2001 ya know.
Admin
Is this where Alex got new job?
Admin
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.
Admin
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.
Admin
Admin
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.
Admin
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:
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.
Admin
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...
Admin
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.
Admin
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.
Admin
Having worked on a system that did this, albeit server side, I can assure you that it's absurb.
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.
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.
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)?
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.
The WoW armoury has a very small set of elements, and is not comparable to the complex markup of a typical website.
Admin
Well, at least the site itself isn't WTFugly ...
Admin
Thanks to you I won't find anything funnier on the internet today. Thanks for making me productive!
Admin
A design like was the holy grail back when WAP was still considered viable. See http://cocoon.apache.org/.
Admin
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.
Admin
Why pay the "cost"? Because XSLT does a fucking amazing job at linking data together.
Admin
As opposed to tighter?
Admin
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.
Admin
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).
Admin
I didn't look at much of what you posted but this should be a Code SOD, not a feature article.
Admin
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
Admin
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...
Admin
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?
This is a legitimate problem, I've been responsible for training new developers; however it isn't really a problem with the technique itself.
Admin
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.