I am trying to work through some issues with Layouts, and I am trying to use the Vaadin ?debug parameter to help me. When I do that, I use the AL command to analyze the layouts, and I see something like this:
Root problems
VVerticalLayout id: PID118
Height problem: Component with relative height inside a VerticalLayout with no height defined.
Emphasize component in UI
Expand this node to show problems that may be dependent on this problem.
I am having problems trying to match this information up with my code. How do I identify object PID118? A couple of times, I have
been able to figure it out by trial and error, but for this particular one, I am stumped. Clicking the ‘Emphasize’ checkbox does
not show anything in my window (sometimes it does, but not for this instance). I’m not sure how to take advantage of the information
available to track down my problem. Is there documentation on the debugger itself somewhere? Please point me in that direction if there is…
You need to set debug ids for all of your components. When you set them, rather than seeing PID118, you’ll see a value you can track back to your code.
This sounds pretty easy, but it is truly a pain in the a**.
They’ll appear null unless you set them. They are only defined as PID118 on the client side when no value is on the server side. If you set your debug id to “foo”, on the client side it becomes something like “PID_S_foo” or something like it (it’s been a few weeks).
If you don’t set it to “foo”, then you get “PID118”.
That’s part of the fun, though, going through and calling setDebugId() on all of your components just so the client side has something meaningful that you can correlate to on the server side…
Oh for the automation part, I wrote up a quick - n - dirty routine that took a component, assigned it a debug id (based upon the class name) and a unique id (debug ids must be unique or you’ll get an exception), then walked all of the child components (for tables it would walk the table looking for components and process them) recursively calling the same method. Not elegant, but it allowed me to assign ids to all of the components in the application’s init() method call and could do the correlation between client and server. The generated ids are not elegant, but they’re enough to get the job done…
Basically, in our main project, all of the major UI components need a “name” for I18N purposes; we’ve created and implemented an interface and series of classes that allow us to dynamically assign debugId (with a hierarchical name making them mostly unique : needed for most test automation tools). I extracted the code, and dumped it in a BitBucket repository - if it’s any use, feel free to use and/or develop further as you like.
Yes, it’s a little bit of a faff naming components - but, ultimately, if you want to have a useful identifier, you really have to do it yourself.
I haven’t really found that naming is an issue here. Even on a very complex layout, you know that your main window has a layout, and that layout contains X components/layouts. Each of those has other children, etc. They’re always in the tree in the order you added them, so you can open the tree in the debug window (next to “Response:”) and open the child nodes until you get to the ID you’re looking for. Just match that up with your code. If ID=X happens to be the 3rd panel in the 2nd layout inside the main window’s layout, for example, you should be able to look at your code and see what that is.
If all else fails, draw a small diagram of your app (in pencil!) to refer to. There’s nothing magical about the information in that tree, so it should match up with your idea of how your UI components are all included in the app.
Probably what I’ve written doesn’t make much sense without an example. Maybe I can do a screen cast some time soon if there’s a need, but what I’m mostly getting at is that you don’t necessarily need to spend time adding these IDs to your objects. The little UI node tree in the debug window is very handy.
In theory, the layout graph should be very straightforward, but in practice, I’m having some issues… I see the following in my log file (from the debugger output):
- HorizontalLayout/135572b (width: RELATIVE, 100.0 %)
- Form/e634bf "Add/Update SSP Record" (width: ABSOLUTE, 200.0 px)
- HorizontalLayout/8d1749 (width: UNDEFINED)
- VerticalLayout/f3cf72 (width: RELATIVE, 100.0 %)
Layout problem detected: Component with relative width inside a HorizontalLayout with no width defined
Relative sizes were replaced by undefined sizes, components may not render as expected.
Which almost makes sense - there is a form with the width set to 200 px. I can see a horizontal layout and a vertical layout, but neither one sets a width value. Are there default conditions I’m not aware of that are causing the horizontal layout to be undefined and the vertical layout to get a specified width - particularly when I am NOT setting it explicitly? I think that must be what is happening, but I’m not sure yet.
Is there a ‘best practice’ related to layouts? Should I be setting the height and width of every layout explicitly to avoid this kind of problem?
Yep, I believe that’s exactly what’s happening. HorizontalLayout and VerticalLayout both have undefined heights, and the horizontal layout has undefined width as well. The thing that’s probably causing your surprise is that
VerticalLayout has 100% width by default . While that may seem weird at first, it makes it easier to layout web pages if you want to do things like center content on the page. The designers probably have a better explanation than I do, but it’s been handy. (Along those same lines, I don’t think layouts have margins enabled by default, but the root vertical layout in Window does have margins on. Makes the page look nice but can surprise you.)
I like your question about “best practices” and am curious about what others think. In my case, I started writing Vaadin apps and didn’t like the idea of setting hard-coded sizes, even if they’re defined in EM units to shrink/grow. I just thought everything should know how big it ought to be! But after a year or two I finally took the time to learn css, and that taught me that it’s fine, and simplifies your life, to set some sizes up front and fit everything in accordingly.
So what I do is set the size for my root container, whether it’s to some EM value or some percentage of the screen. Then I set the size of every layout I add, again to either be full width/full size or some percentage (often you may have two containers side-by-side, one with a hard coded value and the other set to expand to fill the rest, minus margins or whatever). So I try not to have any undefined widths/heights if I can help it, and just taking care of it up-front doesn’t take long and saves trouble later.
I hope that helps. Run your app with ?debug early and often! For what it’s worth, I believe Labels have 100% width by default, which makes sense if you think about them like paragraphs of html content (the browser gives them full width so they’re arranged vertically (I think I’m simplifying that)).
Cheers,
Bobby
p.s. Edited above post to include online link to VerticalLayout javadocs instead of my local copy.
Just wanted to note that, besides the text you see in the log telling you where the problem is, the interactive tree in the debug window is great for troubleshooting. You can leave all the nodes closed except the one with the component giving you trouble, and you have more info there as well. For example:
Near the end there, you see my troublesome horizontal layout with no set width that contains a label. Makes it easy to find my component “PID14” that analyze layouts complained about. (You can also see the default margins on the root vertical layout.) I think it took me a while to realize I could browse the component tree this way.
Note also that with Recent Vaadin versions, you can click a row in the update tree (not sure if also applies to the output of AL) to highlight the component - this can help you find the problematic layout or other component.
Sorry for the delay in responding - I’ve been off for a few days - had one of my hips replaced last Tuesday… Starting to feel somewhat normal again (!!). Thanks very much for the information you gave me last week. I think I need to take a step back and re-visit some of my code - particularly the way I create my layouts. Some re-working is probably in order. But I think I have a better understanding of how the system is supposed to work, and at least some idea of how I can control it.
