How to achieve traditional website behavior with layout panels?

[googelybear]

Hi,

I am developing a webapp that should "behave" like a traditional web
page, meaning that when the content grows in height the browser should
display a vertical scroll bar. Unfortunately I was foolish and jumped
right in on the new, shiny layout panels. As I found out later these
are not suitable for me, as they create a more "application-like" look
and feel with scrollbars displayed in the individual gwt panels
instead of the browser (try resizing e.g. google wave -> When the
available area is too small scrollbars will appear inside all the
panels, the browser will never display any scrollbars) and also they
are working with lots of fixed sizes (in my case the content is
dynamic).
I tried to achieve the traditional behavior with my LayoutPanels but
failed. I couldn't get the browser to display scrollbars, only inner-
panel scrolling, and stuffing a layoutpanel inside a scrollpanel is
not the desirable approach (stuffing layout panels inside non-layout
panels usually ended badly for me..).
So my conclusion is to revert to the "old school" panels. But I am
afraid that support of these will be dropped soon. What do you think?
Are there better alternatives? Anyone fought with a similar problem?

thanks for any suggestions,
Dennis

[Olivier Monaco]

For a "traditionnal layout", I use the "old school" panels. It's not
really a old school, it just has another goal.

Olivier

[googelybear]

Are you not afraid that they will get removed soon?
I always get deprecated warnings when using them: "StackPanel is
deprecated. Use the StackLayoutPanel instead." and same for others
(DockPanel, TabPanel, ...).

What's the official policy on this?

On May 26, 11:49 am, Olivier Monaco <olivier.mon...@free.fr> wrote:
> For a "traditionnallayout", I use the "old school"panels. It's not

> really a old school, it just has another goal.
>
> Olivier
>
> On 26 mai, 10:33, googelybear <googelyb...@gmail.com> wrote:
>
>
>
> > Hi,
>
> > I am developing a webapp that should "behave" like atraditionalweb
> > page, meaning that when the content grows in height the browser should
> > display a vertical scroll bar. Unfortunately I was foolish and jumped

> > right in on the new, shinylayoutpanels. As I found out later these

> > are not suitable for me, as they create a more "application-like" look
> > and feel with scrollbars displayed in the individual gwtpanels
> > instead of the browser (try resizing e.g. google wave -> When the
> > available area is too small scrollbars will appear inside all the
> >panels, the browser will never display any scrollbars) and also they
> > are working with lots of fixed sizes (in my case the content is
> > dynamic).

> > I tried toachievethetraditionalbehaviorwith my LayoutPanels but

> > failed. I couldn't get the browser to display scrollbars, only inner-
> > panel scrolling, and stuffing a layoutpanel inside a scrollpanel is
> > not the desirable approach (stuffinglayoutpanelsinside non-layout

> >panelsusually ended badly for me..).

[SergeZ]

To achieve an old-school HTML behavior of GWT App, I use Vertical/
Horizontal Panels and of course HTMLPanel (which contains the
UiBinder's widgets code).

[Olivier Monaco]

When I want to create a website like app, I use as many HTML tags as
possible with UiBinder. Then, I use CSS to sets the position, border,
color... and never the GWT methods. That way, I have a true web site
but using GWT. I don't like to create a website-like app (something
that looks like a web site but with widgets like in app): you want a
website (HTML + CSS) or an app (Widgets + Layout).

Olivier

[googelybear]

I also prefer to do the styling with CSS and not via gwt methods. But
I still use the panels as one of the strengths of gwt is that it knows
best how to create them in a cross-platform/ cross-browser way and
deals with the browser differences for me (at least in theory). I then
just style them with CSS to look the way I want.
If I would implement everything with html tags I would have to deal
with browser differences again and start implementing browser hacks
which I want to avoid at all cost. What do you think?

Dennis

[Olivier Monaco]

I use both. My goal is to be IE8+ compliant, so many problems go away.
Then, for others, I use GWT to avoid writing CSS hacks.

Be aware that Panels are for Quirks Mode and Layout are for Compliant/
Standard Mode. In the first mode, browser have many differences, which
Panels try to correct. In the second mode, there are, for recent
browser, less differences. I always write my pages as XHTML (strict if
possible) so I don't need many GWT complex component.

Finally, for website, I never use Panels like Stack, Dock... because
its not for website, it's for app. That the reason there must be
replaced by there Layout counterparts.

Olivier

[Stefan Bachert]

Hi Dennis,

I still think what "traditional behaviour" should be. (? not following
the standards?)

However, you don't want scrollbars at your LayoutPanel.

The reason why any widget gets a scrollbar is because it is larger
than its parent and the style overflow is set to auto or scroll.
When the "wrong" widget get a scrollbar you have to change the size of
the panel (div) hierarchy.
Or you have to allow the parents to grow with its child.

When you do not succeed you need to show us your code or at least the
hierarchy of panels.

Stefan Bachert
http://gwtworld.de

[googelybear]

@Stefan: I know the term sucks, but it was the best I could come up
with ;-) As you concluded my main goal is to have browser scrollbar
scrolling and not the "inner scrolling" (lots of individual scrollbars
inside the containers itself, an example for this is google wave).

So in your words "(...) you have to allow the parents to grow with its
child. " That's exactly the behavior of the old panels. I'm not
really clear on how we could emulate this on the new panels (all my
attempts so far failed).

To make a simple example: I have a DockLayoutPanel and somewhere a
button. There is a FlowPanel in the center. Clicking on that button
adds a label to the center panel. Repeatedly clicking that button
fills the center panel and at some point additional labels are not
displayed anymore (simulates the dynamic content). This is as you
wrote because of the overflow:hidden/auto which is set on the
DockPanel - in the LayoutPanels in general - (and is IMPOSSIBLE to
override by the programmer - at least I didn't succeed). If I add a
scrollPanel to the center as parent of the FlowPanel I get said "inner
scrolling" But what I would like to have is that the DockLayoutPanel
itself grows (vertically) which forces the browser to display
scrollbars.

I uploaded the (very simple) demo project here (Just import in eclipse
and run): http://drop.io/gwt_dock_panel

It would be really great if you could share how to achieve the
behavior described above.

thanks,
Dennis

On May 27, 6:55 pm, Stefan Bachert <stefanbach...@yahoo.de> wrote:
> Hi Dennis,
>

> I still think what "traditionalbehaviour" should be. (? not following

> the standards?)
>
> However, you don't want scrollbars at your LayoutPanel.
>
> The reason why any widget gets a scrollbar is because it is larger
> than its parent and the style overflow is set to auto or scroll.
> When the "wrong" widget get a scrollbar you have to change the size of
> the panel (div) hierarchy.
> Or you have to allow the parents to grow with its child.
>
> When you do not succeed you need to show us your code or at least the
> hierarchy ofpanels.
>

> Stefan Bacherthttp://gwtworld.de

>
> On 26 Mai, 10:33, googelybear <googelyb...@gmail.com> wrote:
>
>
>
> > Hi,
>
> > I am developing a webapp that should "behave" like atraditionalweb
> > page, meaning that when the content grows in height the browser should
> > display a vertical scroll bar. Unfortunately I was foolish and jumped

> > right in on the new, shinylayoutpanels. As I found out later these

> > are not suitable for me, as they create a more "application-like" look
> > and feel with scrollbars displayed in the individual gwtpanels
> > instead of the browser (try resizing e.g. google wave -> When the
> > available area is too small scrollbars will appear inside all the
> >panels, the browser will never display any scrollbars) and also they
> > are working with lots of fixed sizes (in my case the content is
> > dynamic).

> > I tried toachievethetraditionalbehaviorwith my LayoutPanels but

> > failed. I couldn't get the browser to display scrollbars, only inner-
> > panel scrolling, and stuffing a layoutpanel inside a scrollpanel is
> > not the desirable approach (stuffinglayoutpanelsinside non-layout

> >panelsusually ended badly for me..).

[Olivier Monaco]

You must not use *LayoutPanel for this purpose. Why not native HTML?

====MyApp.ui.xml====
<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
<ui:UiBinder xmlns:ui="urn:ui:com.google.gwt.uibinder"
xmlns:g='urn:import:com.google.gwt.user.client.ui'>
<ui:style>
.top {
height: 120px;
}
</ui:style>
<HTMLPanel>
<div class="{style.top}">
<g:Button ui:field="button">Click me</g:Button>
</div>
<g:FlowPanel ui:field="content" />
</HTMLPanel>
</ui:UiBinder>
========

====MyApp.java====
public class MyApp extends Composite {
... // UiBinder stuff

public MyApp() {
initWidget(binder.createAndBind(this));
}

@UiHandler("button")
void onButtonClick(ClickEvent event) {
content.add(new Label("Hello world");
}
}
========

Not tested...

Olivier

[Stefan Bachert]

Hi Dennis,

a DockLayout will not grow will the content in "center" is growing.
The "center" of DockLayout get just the remaining space.

I see two ways at the moment
a) After adding widget to the "center" measure its size and increase
the DockLayout accordingly.
The pitfall is the box model. It may be tricky to get the size you
really need (on the other hand, just make it a little bit larger)

b) Do not use DockLayout. Anything based on position:absolute (as
an ..LayoutPanels) do not grow with its children.
In general a <table> based Widget will help, but I usually try to
avoid that. I always found a way with <div>

When I really know your layout, it it probably achievable with
style=float.

Stefan Bachert
http://gwtworld.de

[googelybear]

thanks for all your feedback. After fiddling a bit with manual
resizing I decided to remove the layout panels and go back to the
"old" panels combined with Olivier's approach (using HtmlPanel with
plain html where it makes sense) and live with the deprecation
warnings when using uibinder with the old panels.
Because my expertise with html is limited I will still continue to use
e.g. StackPanel for a menu or similar and see how that works out.
After a day of refactoring I can say that the app is up and running
again (at least on non-IE browsers) but our continuous integration
system cannot build it anymore (as described here:
http://groups.google.com/group/google-web-toolkit/browse_thread/thread/f9905064bd7b485b/457ccdf91e4e9b3f).
But I am optimistic that we can fix this problem soon.

thanks again,

Dennis

On May 28, 5:39 pm, Stefan Bachert <stefanbach...@yahoo.de> wrote:
> Hi Dennis,
>

> a DockLayout will not grow will the content in "center" is growing.
> The "center" of DockLayout get just the remaining space.
>
> I see two ways at the moment
> a) After adding widget to the "center" measure its size and increase
> the DockLayout accordingly.
> The pitfall is the box model. It may be tricky to get the size you
> really need (on the other hand, just make it a little bit larger)
>
> b) Do not use DockLayout. Anything based on position:absolute (as
> an ..LayoutPanels) do not grow with its children.
> In general a <table> based Widget will help, but I usually try to
> avoid that. I always found a way with <div>
>
> When I really know your layout, it it probably achievable with
> style=float.
>

> Stefan Bacherthttp://gwtworld.de