In general I like vaadin but have been extremely frustrated with the user interface design, specifically the layouts. Its very hard to make the application layout and look like I want. What is trivial in HTML has been made unnecessarily complex in Vaadin.
My biggest issue is the fuc** inline styles and heights+widths that get added. This makes it very hard to design the interface. In my recent calculation I have been spending more than 60% of my time just trying to get the user interface to behave. Building the same interface in faces or wicket, for example, is so easy.
A recent example. Added a basic table with two header columns using custom layout. For whatever reason Vaadin decides to give the first header element 800 pixels width thus making the second header invisible.
Another example: its impossible to add margins/paddings to the Vertical/Horizontal layouts without introducing scrolling.
I hope that layout is simplified in the next release. Its too much pain in the butt and a huge detriment to Vaadin’s adoption.
You may want to have a look at wonderful compatible alternative to basic Vertical/Horizontal layout that’s capable of such nice things you’re asking for: http://vaadin.com/directory#addon/dashlayout
I kinda agree that fine tuning looks of Vaadin UI can become frustrating and tiresome sometimes.
tried that too … it has its own issues.
For example it doesnt render if it the VerDash… has, say, a Richtext editor and a HorDash… component. It decides to divide the area equally with lots of empty spaces, but if you add a standard HorizontalLayout it renders properly with no empty spaces.
Besides, that component wont address all needs such as need for grids and lists of items.
Another instance of the sizing issue is with GridLayout. If the parent container layouts are not set to specific heights, Vaadin sets its height to zero!!! Now, if you set the parent containers to 100%, then the grid is displayed but Vaadin chops the grid to the the bottom of the browser screen and also inlines the height so there is no freaking way you can change it.
IMHO Vaadin should not try to set fixed heights or at least provide an option to turn of automatic size calculations or should just leave it alone and let end users decide what the height/width should be, whether in % or in pixels.
My layout is as such: Portlet>Tab>Gridlayout>VerticalLayout>GridLayout [multiple]
. Now I created the same structure in HTML/JSP in 10 minutes with standard tables and div’s. With Vaadin I am banging my head for hours and unable to create this structure.
Being the main responsible here at Vaadin for theme design and CSS wizardry, I’ve banged my head enough times too, to actually try and get some sense to the layouts in Vaadin 7.
I definitely feel your pain, and that’s why I’ve spent more than a pleasant amount of time trying to create alternative layout add-ons, such as DashLayout and WeeLayout. But as you said, they are buggy, incomplete and won’t address all cases. And that’s unfortunately the case it’ll be, since I have very limited time to support/develop them. I know this will sound oh-so-tired, but they are open source and I’m more than happy to get patches.
And I would also appreciate if someone found the time to report any issues with the add-on layouts, so maybe one day I could fix some of them.
What I usually end up doing in situations where I need firm control over the position and sizing of some components, I always fallback to CssLayout (or in fewer cases to CustomLayout), and override any Vaadin specified widths/heights using the !important clause and mix in some relative/absolute positioning, and in over 95% of the cases I can get the job done as quickly as with regular HTML. Takes a bit more planning and knowledge of the Vaadin way of things, but in the end it works (but is not pretty or desirable).
In defense of the Vaadin core layouts, I’ll just say they do the things they promise to do consistently and offer a rich feature set for the CSS/HTML-handicapped developers (devs with desktop app background). And that is what they were designed to do. For web-devs, they’re limiting and bloated.
Of all the frameworks I have tried, Vaadin holds the most promise. From pure Java/swing developers point of view, you are right; this framework rocks and delivers what it promises. However, if you guys nail the layout and allow web devs the flexibility to design cool interfaces easily, I don’t see how this framework cannot become the undisputed leader.
I am a Java developer but for most projects I end up using the creative department to make things look sexy. Those guys only talk CSS. Often those 4 pixels on the left or bottom of a component make a huge difference to the visual appeal.
Your list covers quite a bit. Some things that come to me right away:
perhaps some way to add OL/UL lists. They provide great flexibility in showing numerous components.
improve loading time [perhaps skinny the number of DIV tags, reduce the calculations to speed things up]
browsers are getting better, rely more on the browser to do its thing. Full user control of CSS. NO inline styles please.
wondering why you would even need calculations for expand ratio’s; let CSS control that.
just a suggestion: if it is too hard to replace the core components, then maybe just introduce skinny versions of the core components, like the dashlayout
Will continue posting and providing feedback…
While I cannot provide patches, if layout issues are resolved, I will provide as much beer you can drink and as much pizza you can eat whenever you are in Chicago. :lol:
This is just my 2 cents, I’m by no means an expert in Vaadin layouts.
I really like the default Vaadin layouts (Vertical/Horizontal), when there is need for quick and simple application stuff. I just have to make sure I’m not trying to bend them the wrong way. If I try modify them “web style” (that is, with off-the-top-of-my-head-CSS) they will bite and scream violently. But if I use expand ratios, margins and spacing I can do a lot, and even modify them with CSS to some extent.
Then there are the cases when a client/designer hands over some requirements, and I can tell right off the bat that these cannot be accomplished with the default layouts. It is handy to know the limitations, so I know when to get my hands dirty with CssLayout, DashLayout, WeeLayout etc.
They could be easier, yes. And there are bugs. I’ve reported some DashLayout problems myself. But I think CssLayout, DashLayout and WeeLayout are really powerful tools. If only someone could look at them and submit some nice patches…
In our case we ended up with the following scenario and almost happy so far:
developers only use java methods of layouts and components to build an UI.
our web designer just creates a new Vaadin theme for particular project. Usually this theme contains a lot of styles for the same component. Say, want one HorLayout with fancy image at left border and 3 px margins and another HorLayout with 20 px margins - there will be two style names available for developers for layout.setStyleName(“xxx”) and the same for any other component.
Then we create a visual map where each component rendered and titled, so anyone could easily pickup a proper style name.
So far this works in 90% of cases.
And yes, CSS layout is able to help often to solve tricky tasks and also lightweight a lot the DOM tree.
think that lots of frustration with layouts in vaadin occurs when you try do things vaadin isnt made for.
When i look at vaadin it reminds me on swt,rap,delphi maybe or swing.
I can easily write interaction code like what happens to the table down here when the user clicks on a button up there, displaying everything with vaadin standard components with a standard layout.
Frustration starts when you need a custom ui element and you know this is done easy with html/css/javascript.
You saw it last week on page, it was just an <UL…> with a bit of jQuery… then your… At this point i would recommend you to setup your Webservice HTTP API and doing it the classic way with a javascript framework of your choice. Perhaps its worth waiting for html5 kidding.
For me i make descision for or against vaadin depending on the count of ui controls. If the number of controls and interaction between them is high but layout and design is not a main thing and there is no need for a webservices API, mean an application surrounded with a browser frame then i am lucky with vaadin.
Maybe there will be a programmer of immense mental power bringing both worlds together, desk app and web app but i dont see that… Till then i try to choose wise.
The message on Vaadin’s home page is “…building modern applications that look great”. And as of now, its not easy to build great looking web applications without doing some major major hacks. Modern web applications are complex and I think Vaadin has potential to address the
U and I effectively.
Just the sheer number of layouts is mind boggling. Not only that, their secrets are buried inside forum posts. Each layout has like 20 different rules and gotchas. Development is no longer fun if one stumbles so much along the way. Your advice [or at least the implication]
that drop the framework and use something else is not feasible. Spending time and money in learning and adopting a framework is a huge investment and changing framework is usually the last resort when the framework starts becoming too expensive.
Granted that the community has been superb at helping unravel the undocumented knowledge, but my post was to call out the issues that exist today, with the hope that they will be addressed in the future.
While I agree with much of what you say, I feel obliged to provide a little bit of background:
If we would not need to support old browsers (especially IE6 and IE7), even the relatively rich feature set of HorizontalLayout and VerticalLayout could be implemented more efficiently and simply, leaving most of the calculation to the browser.
It would be possible to use different internal implementations for the same layout on different browsers to take benefit of the browser layout capabilities when possible, but this is quite a bit of work to make work reliably and efficiently, ideally without making themes and DOM structures too browser specific. It might also be possible to simplify the rendering of layouts in other ways when not all of their features are in use. The core developers will definitely be looking into such options in the future, but I cannot give a specific time frame.
Do remember also that Vaadin is aimed at Java developers, most of whom are not expert in CSS. At least all the basic features should be controllable from Java.
What do you mean with “basic features”? I think that vaadin is good for bigger applications with lots of controls. This type of application will be developed in Teams with at least one CSS expert. I cannot agree with the goal
that styles should be controllable from Java. This is, i think a step in the wrong direction.
I think Henri meant a bit another thing - the goal of Vaadin is to let developer to use java-only to build good looking application, e.g. without using any css/html/js (for instance, in some other frameworks you anyway forced to use html in any case, even for hello world app) but this does not mean, of course, this is the only way to work with Vaadin.
Vaadin uses themes to group the web stuff of the visuals (css) and it of course should be used by the team web technologist or css engineer to create and maintain a theme for the application.
So developer uses UI components and layout components, assigning them a style names from a theme used with the app. And also toggling basic features. And designer prepares enough styles for the project theme to handle all the requirements, providing the developer a list of such styles to be used.
For instance, Hor/Ver layouts has feature turn on or off the margins - and this is toggled from java code. But the margins size are (and should be) set in a theme. So several Hor/Ver layouts can have different margins or do not have them at all just by using different styles from a provided theme. And everybody happy - both developer and designer And this is what Henri meant, I think.
So I tried them all… The Weelayout DashLayout, Customlayout… All layouts are very buggy and super fragile. You touch one thing and all hell breaks loose.
For example.
Add a TabSheet to the root of the app and setsizefull on the tab and add any verticallayout. The components inside the verticallayout dont display. Examining the DOM shows that the tabsheet has been set to height of 32px. Must be the the auto calculations.
Ok, so I set height of tabsheet to null and add the weelayout. So now I see the components. Now, I want to test WeeLayouts claim that paddings and margins can be added. So, in CSS style associated with the weelayout, I add padding of 4px. Now scroll bars show inside the tabsheet and height of the tabsheet is reduced to a very small height. uggghhhhh. I cannot set a fixed height for the tab since my components are of varying heights and I cant predict a reasonable height.
Change back to core verticalLayout leaving the margin in CSS. Same problem.
Alsop the performance seriously degrades as soon as the application starts taking shape of medium complexity [in my case I have 4 level deep layouts with grids, vert, horiz and about 10 items showing on a page]
, most likely due to the way layouts are implemented or calculated on the client. Firefox goes nuts asking to stop the script.
So, honestly I am not sure what kind of applications people are building with Vaadin, but it seems to me that Vaadin layout is super rigid and buggy and margin/padding based styling is impossible. The core layouts need to be seriously revisited and improved soon. Btw I did the same thing with YUI and the performance is very very fast. I just hate javascript but I guess I could have mastered it in the amount of time I spent trying all these layouts and trying to get Vaadin to style as per my desire
Not wanting to drag this conversation any further, but I did want to provide the community with an update.
So, I replaced majority of Vaading layouts [Grid, Ver & Hor]
with CssLayout and CustomLayout and was able to control the margins/paddings to a greater degree. Also, I saw tremendous improvement in rendering. It was lots of work but I think worth it. Unfortunately, I do need to to use Tabs and other vaadin containers and that’s where the performance continues to sucks and hard to style them.
So the lesson is that if you looking for high performance web pages and need to style them, stay away from the above mentioned layouts and master the Csslayout and Customlayout, until the Vaadin team provides with skinny and customizable versions of the those layouts.
I think that we could do even better - to get the core layouts to perform better without adding new layouts to the core.
This have been discussed multiple times - mostly in relation to Vaadin 7, but there have not been a proper ticket about it. Thanks to your post - I added these two tickets:
Thank you for submitting the tickets. Capability to freely [or to a higher degree]
style the layouts is equally important [at least in my scenarios]
to performance. Is there an existing ticket on that? Can users create tickets? If not then can you kindly add one related to styling issues [specifically: borders, margins & padding]
?
