you may find this thread interesting: http://groups.google.com/group/google-web-toolkit/browse_thread/thread/ba4b88d2d54b0cd/97157d8e649c716e
On Jul 12, 4:07 pm, Anders <[email protected]> wrote: > Thanks for the quick reply! Sounds like the DockPanelLayout is the way > to go. In my little proof-of-concept app I got lost in what you > described as the 'non-trivial size computation' using just a > LayoutPanel with manual resizing. Hence the question here! > > Keep up the good work with your blog! > > On Jul 12, 3:14 pm, Thomas Broyer <[email protected]> wrote: > > > > > > > > > On Tuesday, July 12, 2011 11:52:27 AM UTC+2, Anders wrote: > > > > Hi, > > > > Reading Thomas Broyer's post 'GWT 2.1 Activities – nesting? > > > YAGNI!' (check it out herehttp://tbroyer.posterous.com/archive/9/2010) > > > Direct link:http://tbroyer.posterous.com/gwt-21-activities-nesting-yagni > > > > really cleared things up with regards on how to handle more complex ui > > > designs. Abandoning the concept of nesting and going for a couple of > > > activity mappers to show/hide display regions as needed. But, after > > > some experimentation on my own I was left with one question that I > > > couldn't find a good answer to. > > > > In the post Broyer mentions briefly that the display regions in the > > > layout needs resizing to fill the empty spaces and says the following: > > > 'Now, here's how you could do it without nesting, just showing hiding > > > display regions when needed (and resizing the others to always fill > > > the same dimensions)'. > > > > My question is therefore where in the code you do the actual resizing > > > of the display regions? > > > It really depends how you're building your layout. If using <div>s and > > FlowPanel/SimplePanels and the like with CSS, and using "fluid layout", you > > don't have to do anything. Same if you're using a DockLayoutPanel (I keep > > talking about "LayoutPanel" in the post, but was actually thinking about > > DockLayoutPanel). > > If using anything else that requires "manual resizing", you'll have to do it > > in your "layout view", and it can quickly get complicated (as soon as you > > have 2 regions that can be hidden/resized independently of each other, > > computing the size of the other regions becomes non-trivial). Using the same > > approach as DockLayoutPanel's internals is best IMO: use > > Scheduler#scheduleFinally to schedule a "relayout" whenever a region > > changes, and in the "relayout" code, you know nothing else will change so > > you can safely compute the sizes of the visible regions. DockLayoutPanel > > makes it really much easier if you can use it. > > > If I understood the post correct the views > > > > themselves should not have any explicit knowledge of sizing, but > > > rather just adapt to the size of the display region. > > > Yes (note, though, that the "should" here is my own opinion, YMMV) -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
