View Full Version : Get viewport to fill up space on page

12 Aug 2009, 2:40 PM
The documentation examples I see mention in passing that viewport is supposed to fill up space. Mine never has, and I was forced to use fixed height for my tabpanel to get it to work at all.

I have tried a lot of different settings, but I don't want to go back to fixed sizes for everything.

This code puts a narrow band at the top of the browser with just the tabs visible.

function BuildViewPort()
KnowledgeBase.PageTabs = new Ext.TabPanel
stateful: false,
autoDestroy: false,
border: false,
hideBorders: true,
title: 'Knowledge Base',
itemId: 'SearchTab',
autoLoad: '/kb/search',
listeners: { activate : function () { ShowSearch('divSearch'); } }
title: 'Forum',
itemId: 'ForumTab',
autoLoad: '/kb/forum'
title: 'Wiki',
itemId: 'WikiTab',
autoLoad: '/kb/Wiki',
listeners: { activate : function () { ShowSearch('divWiki'); } }
KnowledgeBase.PageViewPort = new Ext.Viewport
renderTo: Ext.getBody(),
frame : false,
bodyStyle: 'background:transparent',
border: false,
html:'<div id="header" class="SD_Title"><p><a href="">Web Software Help & Tutorial</a></p></div><div id="divPage"></div>'
KnowledgeBase.PageTabs.setActiveTab("<% = PageTab %>");

12 Aug 2009, 3:55 PM
No need for:

renderTo: Ext.getBody(),

Viewport automatically renders to the body, fits the browser viewport and maintains size when the window is resized.

Why don't you give the Viewport a layout - border would probably suit you, then add your custom div to the north region and the TabPanel to the center region.

13 Aug 2009, 1:23 AM
A Viewport always occupies the whole window area.

But how are you hoping that the Viewport (Which you have noticed is a Container (http://extjs.com/deploy/ext-3.0.0/docs/?class=Ext.Container)) is going to layout (http://extjs.com/deploy/ext-3.0.0/docs/?class=Ext.Container&member=layout) and possibly size any items you place in it?

13 Aug 2009, 8:00 AM
I needed things to at least fill up the screen vertially. Adding layout: 'border' to my viewport as was suggested in this thread fixed this.

Two weeks ago when I orginally wrote this I thought that actually meant I'd have borders so I removed it.

I now have added autoscroll to my tabPanels and it works very nicely in that the tab bar and page title are always at the top but I can scroll the tab panel vertically.

The only downside at the moment is that the viewport now overwrites the background color rather than use what I have specified for my body color. So I am looking for the right way to change this. It needs to be on the body, so that we can specify a gradient bitmap fill if we want to.

BTW, my company is damn impressed with the quality of the interfaces I already have working in such a short time, even with the embarassing newbie confusion I have been going thru. Everything I have been doing now takes a small fraction of the time it took me to do it the first time.

And once it works, it really works, bug free.

It looks like we are really going to go this way and our ExtJS license is going to be purchased really soon now.

13 Aug 2009, 8:05 AM
You should read and think about what I posted.

Just hearing that an incantation of adding layout: 'border' just magically fixes something without having to think about it will come back and bite you.

You need to understand that a Container's layout is what arranges child Components, and you MUST consider this, and choose an appropriate one to get the layout you want to see.

13 Aug 2009, 8:41 AM
I understand what layout does NOW. I just didn't understand what it did when I first implemented the viewport.

One of the ways I deal with in learning new code is to "black-box" the stuff I don't yet grok. I put inputs into it and I get results, not quite understanding why, but in the meantime I am actually wrapping my head around other things and understanding them at a high level of detail. Eventually I get back to what I have black-boxed, usually because it becomes necessary to understand them to get the high level of control I prefer.

I'm still having some trouble finding a single place listing all the different types of layout and what they do. They are referred to in passing all over the place, but not in an organized way that would help newbies like me to get my head wrapped around this.

I have just received the "Learning Ext JS" book, so I will be reading that too.

13 Aug 2009, 11:20 AM
They are listed in the API docs right there in their own branch of the tree!

13 Aug 2009, 5:52 PM
I'm sorry I didn't notice that without you pointing it out.

I have clicked on references to "layout" in the text of the interactive document, but they link to a definition of the term and don't go back to the much better explanation you get from clicking on the tree.

it just never occurred to me to try to find a better reference by finding the term in the list.

13 Aug 2009, 9:21 PM
Errr, have you been labouring under the misapprehension that whenever anyone told you to read the docs, and was annoyed when you did not "get it", that was because they thought that this was adequate?


These things expand!

See the arrow in the margin?

When you click the margin, you get:


The reason why the API docs are pointed at so much is because I have spent probably several hundred hours doing pro bono documentation work creating a massive volume of carefully written documentation.

In a lot of Ext source files, the volume of documentation far outweighs the volume of code.

13 Aug 2009, 11:53 PM
While the whole thing is a massive and in some ways deeply impressive amount of work the interface needs some usability reviews.

On the subject of expanding the topics, most of the time expanding them reveals a single additional line or two. The text rarely links back to a higher level discussion of the item, and because of the lack of global search capability, you can't get there unless you already know the answer.

You already know HOW to get there because you understand this. I don't yet.

There are several long lists to open up on the left. Which one should I look thru to find the property i am looking for? Especially since I really don't know what I'm looking for yet?

Some people like me are not very good at reading down vertical lists to find things. So we search for them and in most interfaces, this works. I have been searching other programming documentation for years this way and it so often works, that when nothing comes up in searches of this document, I assume that the topic I am looking for doesn't exist and give up and try to find the answer in the forums instead.

It took me a quite a while to realize that I shouldn't click on the cell itself, despite being the logical thing to do pops a page of raw code that is pretty much gibberish when you are trying to learn basic things.

But opening these up with the little grey arrow is very rarely much more informative than the small part you show.

The main search interface limits what it finds too much. It doesn't search for key words and phrases, it only searches for ExtJS elements and properties. Not very helpful if you have no idea of what to search for.

BTW this expanded listing you just showed lists the layout types but doesn't explain them. Very nice but not informative.

The hyperlinks most often bring you to uninformative leaf nodes without a clear way of navigating to a higher level that explains related elements in context.

The lack of context is the problem. The whole document would be far more useful as a single large PDF because I could search it up and down for what I want, and the larger more useful contextual descriptions would be easier to find.

At least some of the documentation needs to be searchable on a task-related keywords and phrases, so that when I have an issue I can find the functions and properties that solve the problem. It is well indexed on ExtJS keywords, but newbies don't know what to look for.

A pdf would also get indexed on google so that we could find stuff inside it better.

14 Aug 2009, 1:13 AM
There needs to be some kind of tagging system in the comments.

{@keywords layout,container,viewport}

Which would then add those to an index entry for the member being documented.

14 Aug 2009, 1:15 AM
But I strongly disagree with your "very rarely".

Whenever a class member needs some explanation, eg something a bit more complex than the title config, there is more available when you expand it.

And if not, please tell me which ones need expansion.