CssLayout2 component

Vaadin 6 / 7 / 8 Framework UI
1

I’m interested in developing and contributing a new CssLayout component (I don’t have a name for it yet) and I wanted to vet the idea with veterans before I start development.

We make extensive use of CssLayout and CustomLayout in our application (in fact, that’s the only layouts we use). With CssLayouts, there are 3 divs:

  1. v-csslayout
  2. v-csslayout-margin
  3. v-csslayout-container

To make styling easier and the page render faster, our ui designer thought it be a good idea to reduce the # of div’s with our css layouts. So i was thinking of removing #1 and #2 (or at least #2) if possible. Before I do so, i wanted to get inputs into why this would be OK or if it’s a horrible idea.

If it turns out to be a good idea, then I’ll begin looking at the code. I assume I can learn how to develop it by looking at CssLayout code right?

Thanks!

duy

2

Hi!

It is a fine idea. CssLayout originally (when it was not a core part of Vaadin, but a FlowLayout in FastLayouts project) had only one div element too. The reason why we added those elements was that the Layout interface in Vaadin has setMargin method and Panels (including Window) originally required an instance of Layout instead of ComponentContainer. We didn’t want any non-functional API to the core product. Originally it didn’t support generic component features like caption and icon either, which will aid a bit in rendering performance too.

Finding a previous version from SVN you could find that implementation, but I guess the project is not completely compatible with 6.2 at that point.

cheers,
matti

3

The svn location for FastLayouts project

http://dev.vaadin.com/svn/incubator/FastLayouts/src/com/vaadin/incubator/fastlayouts

4

Thanks for the very useful reply Matti.

However, I’m confused about one thing. IF I can make the previous version of CssLayout (using 1 div) a new component that is compatible with Vaadin 6.3, would it be incorporated into 6.3 and future releases? I think having a “lightweight” CssLayout component that is just 1 div would be immensely useful and I would volunteer to make it compatible with 6.3. My question is IF i can create such a component, would it be integrated into the main Vaadin releases so that I don’t constantly have to check compatibility for each release?

Thanks!

duy

5

Having a really, really, really simple layouts in the core would probably be a good idea, and I’d be willing to propose the idea of splitting the current Vertical/Horizontal layouts into basic and more feature complete versions. Strip out expand ratios from the basic version, and strip out caption support from the advanced version, and that’s about it. Both could be made with a single DIV element.

And for a working version of a feature rich one-DIV-solution, see my
DashLayout project
. It’s more than you’re asking for, but could be stripped down to the bare minimum to have the CssLayout2 you’re looking for.

6

Hi Jouni,

I understand clearly thatyou’re proposing Vaadin have 2 new components (simplified HorizontalLayout and simplified VerticalLayout) in addition to the existing HorizontalLayout and VerticalLayout in the main Vaadin releases.

But what about a simplified CssLayout in addition to the existing CssLayout? If I did what you or Matti suggested and modified and existing component, updating it to work with Vaadin 6.3, would the team be willing to include it in the main release? As I mentioned, having it in the main release branch allows a great amount of stability for the component and I wouldn’t have to recheck the component every time I update to a new release.

duy

7

Good idea, but I’d go a bit further still: modify the current CssLayout to have only one DIV instead of three. There’s no need to have those three just to provide margin support for CssLaout (or any other layout).


Speaking in a more general sense
, my personal feeling is that our current layouts are way too bloated to be efficient and usable. They just try to tackle all problems with only a few classes, and the result is suboptimal for everyone. In theory there are no problems with them, the feature-set is good, but in practice many of the layouts are too slow and restricting in styling.

What I tried to convince to myself and others in our team is that it’s totally possible to build complex layouts with only one DIV element that allows flexible styling, and performs quite fast as well (Firefox is still a problem). But DashLayout isn’t the final solution either.

That’s why I’m willing to propose the branching of expand ratios away from the core layouts. Expand ratios are a relatively rarely needed feature, and most of the time it’s used only for the larger parts of the view, not when you’re laying out components for a simple form. The basic task of getting stuff on the screen in some orientation or a grid should simple.

And if we’d split expand ratios away from VerticalLayout, and implement it using a single DIV element, that would basically be the exact same thing as CssLayout, right? Probably it would still make sense to extend either from the other, but the foundation would be very similar.

Then the version that do support expand ratios could instead ditch generic component caption support, which causes a lot of gray hair when combined with expand ratios and spacings.

My needs are mostly dictated by my experiences implementing some application themes/layouts, and hence I can’t speak for everyone who might for example work on forms and people who are less than familiar with CSS.


Would there be interest in forming some sort of group to discuss the layout system in general?
 Ideas about how to improve, make laying out components easier and more predictable/understandable?

8

The layout system was fully revised a little over year ago in 5.3. Ripping it a apart just one year after it has been revised would be really strange. Doing that without an extensive study on the problems, validation of their existence and assessment of their impact as well as proposal and prototype for an alternative would be just stupid.

That said, admittedly Vaadin has one of the most feature-rich layout system in any UI framework. This brings some challenges for layout performance, but also gives a lot of power to the developers using the layout system. In my opinion there are two things that could be done:

  • Develop additional layouts that could be used side by side with the current ones, but which trade features for raw performance. CssLayout is an example of this.
  • Optimize the implementation of the existing layouts. I am sure that the most used layouts could be optimized a lot if we accept that the implementation complexity goes up. Because Vaadin nicely hides this complexity from the user, it is only matter of cost for maintaining more complex implementations for core layouts. (As an example, VerticalLayout could turn on simpler rendering modes when the child components doesn’t use alignment, caption, expandRatiom, etc features).

Both of the above would need good benchmarks. Development of those benchmarks is the best starting point. Those benchmarks should also try to compare the layout performance to a set competing frameworks.


Summary
 I strongly oppose ripping apart exiting stable APIs and propose to 1) optimize implementation instead and where optimizations bump into walls 2) to provide simpler alternative layouts that could complement the existing ones.

9

While not all layouts have been systematically benchmarked, it is obvious that there are performance issues with the current full-featured layouts.

Simple alternative layouts could help in many cases. Many of these could be trivial subclasses of CssLayout or its simplified version.

Note that “adaptive” changes in the full-featured layouts could improve the situation somewhat, but automatically changing the DOM depth etc. could wreak havoc with theming of layouts, and the interactions need to be carefully considered.

10

My main problem with the current layouts is probably the total inability to fine-tune the component positions, and that all component slots are clipped, making it impossible to have components “flow out” their accommodated space.

Performance comes second on the list. It creates a mental block for me and prevents me from nesting multiple layouts inside each other to create more complex views.

If we can fix these two, I’m fine with the current API and implementations.

But I guess my other issue was that I personally have no idea how people would want to lay out components in advanced/complex situations. I’m happy using just CSS for everything (provided that it would work, as it currently does not), but what about others? I have no experience in desktop software layout systems, how do they solve these issues? What kind of API do they provide for fine-tuning layouts?

11

This is unfortunately the case. Fortunately DOM itself isn’t necessarily the element that creates performance problems - it is more likely that switches between DOM operations and JS is the bottleneck. For example, if we are in a situation without captions, expandRatios and alignments - it is probable that we could implement quite a bit faster VerticalLayout even if the DOM depth stays the same.

Also - in some cases it might be acceptable to vary DOM depth, if (and only if) we would have a strict documentation on what part of the DOM structures can be considered to be stable “API” to CSS against. Most probably it is acceptable that all parts of the DOM doesn’t have to be considered stable “API”.

12

Now I did not get it. By “fine-tuning” you mean CSS? If so, shouldn’t this be mostly applicable to CSSLayout?

I think that many of the problems will be solved as soon as WYSIWYG editor is ready. Absolute layout is
very
 flexible and will probably solve most of the advanced layout needs people might have.

13

I meant that I frequently want to add some space around some component that has a stylename specified (using CSS margins), and maybe shift it’s location a bit (again, probably using CSS margins). I’m fine if this is doable with at least CSS, but I was also wondering if others would want to do such things without CSS, maybe using some API? Dunno, just trying to get opinions.

You’re probably right.

I’d say it needs a lot more work. It uses far too many DIV’s, and the component positions can’t be specified using plain CSS. I would like to just add components in Java code to the layout, and then position them in CSS using the component stylenames. Currently this is not possible.

14

To my mind the alternatives are: 1) add support for CSS margin/spacing/borders to veritical/horizontal layout, 2) use CSS layout in cases where the layout needs to be tuned with CSS.

The first one is probably doable, but adds complexity and weight to already complex layouts. To my ear the latter option sounds more “correct”.

Why absolute layout should be tunable with CSS? Why not use CSSLayout?

15

Hi folks,

I appreciate all the inputs, but I’m not sure about what exactly will be done at this point. It all comes down to:

  1. I need a lighweight CSS Layout that only has 1 div (2 if absolutely necessary, but 1 is much preferred).
  2. I’m willing to modify an existing component to get it to be compatible with Vaadin 6.2.3 or 6.3
  3. I’d like it to be released with the normal Vaadin components if possible.

Should I file a bug so that I can track it? I’m quite confused about what is being proposed here.

Thanks,

duy

16

Sorry for making so much noise, it’s turned into more of a brainstorm between me and Joonas :slight_smile:

My opinions:
We can’t change the current CssLayout radically (as in removing two DIV elements completely from it), since it’ll break some existing apps. This can be done in version 7 earliest. You can create a ticket for it if you wish.

Making your own version based on current CssLayout shouldn’t be difficult. If you don’t absolutely need Layout.setMargin(boolean) to work, you can ignore those methods. Then you don’t have to worry about measuring any margins, just place the components inside one DIV in the right order. Compatibility shouldn’t be a problem, you can make it work with both 6.2 and 6.3 versions.

I’ll answer Joonas one more time, then I’m done here.

(That would be margin/border/padding, right? Spacing is a different thing) I wouldn’t say it adds much complexity. We already measure “margins”, adding borders and padding to that is a low overhead.

But having at least border support for the core layouts is IMO crucial, otherwise me and other theme developers are forced to jump through hoops with CssLayout and CustomLayout every time we want such a simple thing as a border. And making it work even with CssLayout and CustomLayout sometimes requires hackery that I wish would be abstracted away into the layouts themselves (most of the hackery is covered already, thanks for that).

You have a point there. Wouldn’t it make sense then to extend AbsoluteLayout from CssLayout (in the future)?

But I guess it comes down to intuitiveness and ease-of-use. CssLayout leaves all in the hands of the developer, when AbsoluteLayout should try to abstract away all browser differences, so I will be able to use the same logical CSS/API for all browsers. And the trouble comes of course from IE6, most of the time.

17

Actually I think that it has been a good brainstorm :)

IMO:

  • CSSLayout should have been without support for setMargin() from the start, BUT as it now supports setMargin() we should not remove this functionality. Not in 6 nor in 7.
  • Creating “SimpleCSSLayout” is really easy. This could be done in ones own project or even better - published in the upcoming Directory as an add-on component to Vaadin. I think that the line between core and add-ons will be fading as use of add-ons becomes trivial with the Directory.

In general. All the CSS finetuneability that could be added to core layouts is good as long as it doesn’t add too much rendering time overhead or implementation complexity. How much is too much is a good question. I think that investing in making core layouts perfect in all ways - features, performance and correctness - is really important. Everyone should be able to trust that the core-layouts work fine - even when they are a bit abused.

When there is a need for additional layouts, in most cases they should go to Directory where we have much more freedom for selecting the level of features supported, quality and performance.

How to proceed? Please write tickets about core layout enhancements :)

18

I agree with both of you, Jouni and Joonas:

  • there is a problem and a discussion group on layouts would be useful
  • side projects are useful to mature a new API.

As a programmer using Vaadin, my main concern about Layouts is speed. I don’t know how they are implemented. I’m not sure that making the implementation more complex to gain some performance is the the most appropriate direction, because I don’t use often many of the features of layouts. Having simplified 1 div, very fast layouts is fine for me. I just need them to stack inner components vertically or horizontally.

Do you think it would be possible to favor composition over inheritance in the API? I mean to add features as we add decorators in the java.io API.

Layout layout = new NakedLayout();  // One div, do nothing.
layout.addBehavior( new VerticalDirection() )
      .addBehavior( new Caption("Hello, I'm a caption") )
      .addBehavior( new Margin("10px, 10px, 0, 0") )
      .addBehavior( new Spacing("15px") );

Most people would add no caption, for example. But if I need a caption in one of my windows, I can add it easily, and maybe for that one layout, Vaadin will produce 10 divs, I don’t care (if in all the other cases it produces 1 div and it’s client-side rocket fast).

Do you remember what people were saying about Java during the previous century (about AWT-Swing apps) ?

  • it’s SLOW
  • it’s UGLY

Hopefully, Vaadin is beautiful. I would not want people to say it’s slow because average programmers like me misuse layouts.

If I teach Vaadin to a newbie I’d like to tell him:

  • use that featureless layout, because you do not need the features of other layouts for your application in the frame of the course.
  • be aware that if you need more feature in a few weeks for one window, other layouts laying there, ready to serve.

That way, the first Vaadin web site of newbies will all be rocket fast :wink:

19

From Jouni;

Yes, yes, yes, I’d like to have that!

For styling concerning the whole application, it’s good to have it in a centralized CSS.

But sometimes you want to tune the style of one specific component in one window and nowhere else in your app.
In that case I don’t want to split my UI code between a .java and a .css file.
I was to happy that, thank to Vaadin, I could stop jumping between .java, .jsp and.xml files.

Having something like this would be useful to me:

Component c = new Button();
c.setInnerStyle("padding 0 0 0 38px; font-color:red;");

That would render a style=“padding 0 0 0 38px; font-color:red;” attribute inside the html component tag (or the div around it).

When people have redesigned HTML into HTML+CSS, didn’t they leave the option to define some of the styling inside the HTML file? Why would a Vaadin programmer be forced to use a separate file?

I can hear some purist’s reaction from here:
But some bad programmers will over-use that possibility.

I would reply that bad programmers write bad code whatever you do for them.

20

I actually thought about this and implemented a quick proof-of-concept about two years ago for the layout and component size changes made for IT Mill Toolkit 5 (back in the day when only a couple of components had setWidth/setHeight).

I think the problem was that the general API doesn’t use composition anywhere, so some of us here at IT Mill were against of adding anything else than plain inheritance to it.

I’d be willing to try out composition. A very good suggestion IMO.

But the problem really isn’t on the server-side. It’s the client-side implementation that’s hard to maintain. With composition, the situation doesn’t change that much, the generated UIDL would probably be pretty much the same as today. We’d still have to decide how to implement the features: in one class, or with multiple classes, each having different implementations.

Would it be necessary to be able to remove some behaviors at run time? Say remove a the spacing or margin, or switch the orientation of a layout during one request-response cycle? These always cause even more headaches at the client-side, when you balance with ease-of-maintenance/readability and performance.