Wednesday, October 7th, 2009

Ext JS in Action: The Table Layout

Category: Books

<p>extjsbook

Jesus Garcia kindly gave us excerpts from his book Ext JS in Action.

Now he is back with a new excerpt from a chapter on the Table Layout (download PDF):

The table layout gives you complete control over how you want to visually organize your components. Many of us are used to building HTML tables the traditional way, where we actually write the HTML code. Building a table of Ext Components, however, is different as we specify the content of the table cells in a single dimension array, which can get a little confusing. Once you’ve done these exercises, you’ll be an expert in this layout.

Manning has also given us the discount code “ajaxian35? that gives you 35% off of any version of this book. So, if you like what you see in the excerpts, get it cheap!

Related Content:

16 Comments »

Comments feed TrackBack URI

Sorry, but using the tag for layout is STILL full of fail. There are way too many reasons NOT to use the tag for layout. A table should be used for TABULAR data. Would you use Microsoft Excel to layout your design? I appreciate the free chapter, but this would not

Comment by JoeMcCann — October 7, 2009

…sorry got cut off

…but this would not be a quick sell for me to use ExtJS.

Comment by JoeMcCann — October 7, 2009

@JoeMcCann

1) I don’t know if the actual “table” tag is even used in an ExtJS table layout (completely different things).

2) Microsoft Excel was not originally made to layout designs — the “table” tag WAS originally made to provide a page layout. Your analogy doesn’t fit.

Comment by mdmadph — October 7, 2009

And today’s award for the guy who most loudly talks out of his butt: JoeMcCann!

Comment by ajaxianreader123 — October 7, 2009

Hurrr

Comment by Darkimmortal — October 7, 2009

I love the whole tables versus no tables debate… has to be one of the more stupid debates in history. Let’s go over the reasons tables are stupid, as stated in the link provided by Jadet:

* “mixes presentational data in with your content.”

Ok, fine, I don’t disagree, and the forward-thinking “semantic web” crowd have a valid point here. But…

* “This makes the file sizes of your pages unnecessarily large, as users must download this presentational data for each page they visit.”

Err, if I DON’T download presentational data for each page I visit, what in the BLUE HELL am I looking at on my screen?!? CSS is wonderful, but CSS applied to no content looks like…umm… what’s the phrase… A BLANK PAGE?!? I don’t know, seems like I have to download presentational data either way. I suppose someone will come along and say I’m defining “presentational data” wrong, so I’m all ears.

* “Bandwidth ain’t free.”

Yes, granted. The whole “size and speed of rendering” argument is definitely valid. However, have you ever really compared a complex CSS-based layout to a similarly-complex table-based layout? I have. Guess what? The difference isn’t typically that big a deal in terms of bandwidth utilization. I’ve even in one or two cases found the CSS approach to result in MORE bits going across the wire. I’m sure the CSS wasn’t as perfectly-optimized as possible, but then, neither was the table layout!

Processing speed is the other typical argument, and while I accept that *generally* CSS-based layouts are less processor-intensive, I’ve seen some cases were the exact opposite is true. Remember, tables have been around before CSS (at least, CSS with any sort of complexity)… browsers are pretty well optimized for tables at this point and are I think only now being optimized really well for CSS, in the past 2-3 years maybe.

* “This makes redesigns of existing sites and content extremely labor intensive (and expensive).”

Again, while CSS is very cool, I’ve in my entire life met so few people that find designing a CSS-based layout to be easier and faster than table-based layouts as to not be statistically important. I agree, if you’re an absolute CSS God it’s probably no big deal to knock out virtually any layout, and it’s certainly no more difficult for you than tables… but there’s not many of those folks around frankly. Most of us can manage what we need to with CSS, but it’s often times a bit of a struggle. You’ll never convince me that designing with tables isn’t easier and faster, and therefore cheaper and less labor-intensive, than a CSS-based layout, unless the layout is so simple that they’re about the same anyway. Maybe 10 years from now I’ll say something different, but not now.

* “It also makes it extremely hard (and expensive) to maintain visual consistency throughout a site.”

If this is taken to mean that it’s easier with a CSS-based layout to change the layout across an entire site, then yes, absolutely, no argument. There’s certainly server-side tricks you could play to make tales about as easy, but I’m an RIA man myself, so even *I* don’t like that answer :)

* “Table-based pages are also much less accessible to users with disabilities and viewers using cell phones and PDAs to access the Web.”

I want to see evidence of this. I’ve personally seen FAR better support of tables than CSS across constrained devices such as cell phone, and I dare say that screen readers can deal with tables just fine from what I’ve seen.

I’m not necessarily taking sides here… I think there’s some fair points on both sides… but, it does seem that the CSS purists are the louder, more obnoxious side of the debate, and that turns me off. At the end of the day, let’s put the religion aside and just get our work done, how’s that?? :)

Comment by fzammetti — October 7, 2009

@fzammetti: Those are arguments a lot of people use who don’t feel comfortable enough with CSS. When you have to make it as a freelancer you’ll soon realise that the winner of the tables vs. no tables debate is CSS.
You won’t get many high-end clients if you are still using tables for layout since those clients know what they are doing. They want maintainable code with seperation of styling and content and won’t even consider you for the job if you are still advocating the use of tables.

Comment by Jadet — October 7, 2009

@Jadet: I’ve had no trouble finding work regardless of what position I may hold on this… I produce results regardless of anything else and those that employ me reconize and very much appreciate that fact :) In any case, I’m not so much advocating one thing over another as I am simply pointing out that the debate is, IMO, a tired one (and that at least some of the talking points on the CSS side are, I believe, at least debatable… but to be fair, the same can be said of the pro-table camp’s arguments).

To me, it’s akin to saying all planes should always be jet planes because jet planes are clearly better than prop-driven planes. It’s hard to dispute that by most criteria a jet plane wins, but there’s plenty of people who would advocate the other way, and for quite valid reasons.

I have no problem saying we should favor CSS, and that we should only use tables by exception, I think that’s the right approach frankly. To say you should ONLY EVER use CSS though, in my mind, is far too rigid a mindset… as a client, I’d actually be more inclined to turn away someone who appears to have an inflexible mind over someone I might disagree with about something.

Comment by fzammetti — October 8, 2009

ExtJS offers both approaches. There is the table layout for when you need it, and the hbox layout for when you want to lay out content horizontally, as well as the border layout for the typical west/center/east layout. It uses the most optimal html/css elements for each. For a table layout, the most efficient and performant markup is a table tag (why emulate a table in css when html already contains the primitive?).

Comment by Joeri — October 8, 2009

“A table should be used for TABULAR data”

Err, yes. That’s why there is the possibility to use layout: ‘table’

It’s if you are wanting to present data in a tabular manner.

If not, use another layout!

(sheesh!)

Comment by ExtAnimal — October 8, 2009

The debate over CSS vs Table are irrelevant when placed in the context of layouts with Ext JS.

Comment by JayGarcia — October 8, 2009

@JayGarcia: I basically agree with you, but the word “irrelevant” may be too strong.

Given some of the arguments against using tables for layout, things like bandwidth and CPU utilization and “semantic” correctness for example, it *does* I think matter, to some people at least, what Ext JS does underneath the covers. From what I remember the last time I looked, Ext JS does in fact use tables quite a bit (I remember the generated markup for the Grid in particular being very table-y).

I agree that when you’re developing an application with Ext this generally isn’t your concern… I know it isn’t mine, and I do *a lot* of work with Ext… but for those that are vehemently anti-tables for layout, I would expect they’d raise the same sorts of objections and apply them to what Ext JS generates.

Then again, I could argue that using Ext, or any good toolkit like it, is another reason the CSS vs. tables argument is less important… the whole goal of abstractions, of which Ext JS certainly is one, is to hide details to make building more complex things easier (and obviously to stop reinventing the wheel every time). At what point do you stop worrying entirely about the details of a given lower level of an abstraction? Is one level removed OK, or do you need five before you don’t care? Or is there NEVER a time where you ignore the details? (at which point you’ve got to wonder what the point of an abstraction is!)

I personally don’t worry about what Ext JS produces code-wide (unless I have specific reason to), but at the same time I can see where someone else would be concerned with that… I wonder if that means that the “CSS-only” crew is inherently anti-Ext JS and indeed anti-any high-level GUI toolkit like it that isn’t 100% CSS-based? I’d be willing to wager that few toolkits, if any, actually are as pure as the CSS-only folks say markup should be… Logically it seems like they’d HAVE to be against these toolkits, no?

Comment by fzammetti — October 8, 2009

“I remember the generated markup for the Grid in particular being very table-y”

Which is the most appropriate thing in the world. It’s a table.

Comment by ExtAnimal — October 8, 2009

@ExtAnimal: Let me clear by saying that I don’t have a problem with what Ext JS does. That being said…

There’s a difference between a table for tabular data and tables within tables within tables and so on, which is what I remember seeing. I don’t know if recent versions have moved away from that, but that’s what I remember seeing. I think even the most ardent tables supporter would say that’s probably not appropriate, when looked at from the point of view of CSS vs. tables for layout.

Comment by fzammetti — October 8, 2009

I see what you mean.

Well, I think that the TableLayout layout manager is not widely used for general layout of Components in Containers.

More likely since Ext 3 came out would be the “box” layouts, VBoxLayout and HBoxLayout which offer flexible sizing and laying out of child Components based on a scheme similar to that outlined here: http://ajaxian.com/archives/css-3-flexible-box-model

Comment by ExtAnimal — October 9, 2009

Our website uses a solid mix of tables and css… that being said we have a lot of tabular data too. And I mean, just to drive home the point, we have tables, that are styled, with CSS. They’re both just tools to an end, guys. It’s not that CSS can’t do everything… especially if you got some CSS3 support you can do pretty much whatever you want. The fact is though, most of what CSS3 can do is not new (most – I do love my automatic rounded corners, though, thank you) – you could do it with tables before. Some things are still, today, easier with tables – proper centered vertical and horizontal alignment, together (without indecipherable voodoo), anyone?

What it comes down to for me is, CSS only takes you so far when 40% of your users are still using a browser that was written when CSS was still just starting to take hold (that is, IE 6). I don’t think most of the table-lovers of the world would have much of a problem switching to full CSS for most use-cases if all the browsers they had to program for actually implemented CSS well. The fact is, for many of us, one of the largest target audiences does not use such a browser. I try, I really try, but when I spend 3 hours on a layout, get it working in 20 minutes for all but one browser and have that last browser just not cooperate and not cooperate, all the while knowing that with two little table tags I can get that browser to do exactly what I want (and all the other browsers would work with that too) – yeah. I’m going to just use a table.

Here’s an example. You’ve got a row of thumbnails (variable width). Each thumbnail can have completely different dimensions (but must fit in, say, a 60×60 square). On the upper-right corner of that thumbnail, you want a circular delete button where only 1/4 of the button overlaps the thumbnail. That delete button only appears when you hover over the thumbnail, and when you hover over the button, it also has a separate hover and active state. The thumbnails must be dynamically resizable with a slider, and even after resizing that delete button’s gotta be in the same place. The thumbnails all must be vertically centered with each other (remember, they have different dimensions), and there should be a vertical line between each thumbnail which does not touch the top, or bottom of the container. (I know, sounds really complex – but I’ve hit this exact use case over, and over, and over again – my designers love this stuff). Now, tell me, how do you do that in IE 6 without tables?

This is when the CSS purists usually say to me, “well, you should just make a simpler layout”. Right.

Now, if you think that’s bad, imagine what the Ext people have to deal with to work some of their magic with grids, and trees, and toolbars. And keep it IE6 compatible. And you’re going to harp on them, because they use tables sometimes? You should be grateful it works at all. When you get proper floats and margins, all “display” options (including inline-block), vertical-align, and max-width/min-width working in every major browser, then we can start preaching about the misuse of tables. Until that day (and I don’t know about you, but I’m definitely looking forward to 7/13), let’s just be grateful we can accomplish these layouts in the first place.

Comment by jove4015 — October 18, 2009

Leave a comment

You must be logged in to post a comment.