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.
