The Daily WTF: Curious Perversions in Information Technology

2012-01-26 Reply Admin

I've actually seen this done in the wild.

It's horrifying.

Lockwood · 2012-01-26 Reply Admin

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...

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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

2012-01-26 Reply Admin

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?

2012-01-26 Reply Admin

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/

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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".

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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 Reply Admin

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.

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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 Reply Admin

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">Black</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

wbrianwhite · 2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

Mr. J:
... What's missing is the SQL Server stored procedures generating XML

SQL Server 2000, natch.

2012-01-26 Reply Admin

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 Reply Admin

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 Reply Admin

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.

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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 Reply Admin

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

2012-01-26 Reply Admin

Ah, but with zero-based indices, comment 0 is still the first comment, and comment 6 is the seventh. Get back to school, tighter.

2012-01-26 Reply Admin

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 Reply Admin

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.

2012-01-26 Reply Admin

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)

2012-01-26 Reply Admin

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

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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)

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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 [image] tag. And what zero-time tool did you use to encode the image?

2012-01-26 Reply Admin

We already have better tools for doing all of this.

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

You get major benefits, which include:

It's performant with no real effort.
It's very portable when you use JS frameworks (jQuery/underscore/backbone, etc).
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).
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.
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 Reply Admin

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.

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

Previous version of armory did.

2012-01-26 Reply Admin

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.

2012-01-26 Reply Admin

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 [image] 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

Sketchy Skechers.com

Leave a comment on “Sketchy Skechers.com”