I am spending alot of time positioning my Vaadin components and was wondering what other people's experiences when developing their own Vaadin applications was when layout out their GUIs.
Regarding CSS positioning:
My experience/knowledge as a former Vaadin core developer, current Vaadin application designer/developer is that you shouldn't touch the positioning of the components using CSS, unless you use either CssLayout or CustomLayout.
Inside those layouts you can do pretty much anything CSS permits (Vaadin adds some inline sizes to the contained components, mind you), but with the other core layouts I advice that you don't try to do any fancy tricks unless you know the inner workings of the layout system intimately :)
For options to the core layouts, see the DashLayout and WeeLayout add-ons, which provide some additional freedom in terms of CSS styling.
But if you're talking positioning components using the Java API's then please clarify a bit where you're spending a lot of time.
Coming from desktop world the AbsoluteLayout using pixel positions and sizes has proven very straight-forward way to do component layouts.
That is a bit trade-off between Java-only layout and powerful web-style layout mechanism you get with CssLayout and CustomLayout, but you should get quite far by smartly mixing of these.
I only use css to style the background of some component or panel...
The main layout of my applications is usually looked like the AddressBook demo, sometimes look like iTunes. (with some splitpanel, expandratio or gridlayout)
And I use a lot of window (calling center() almost everytime).
I used to worry about the deep hierarchy of the component tree making it hard to do communication between components. But with the BlackBoard add-on, now it's easy.
I found this something interesting but never have time to try.
And I'm thinking of implementing some declarative form/table field factory (using xml).
imho, developing with vaadin is such a joy...
Related
preamble: I'm an advanced Vaadin developer (I've used 6, 7, and now all my project are migrated to Vaadin 8).
I'm starting to study Vaadin 10 / Flow, but I find myself in some hot waters.
What I'm actually struggling with is the "project" itself.
The more I deep into, the more I feel like this framework is moving into a css / html based framework, which requires more css/html knowledge than java.
What I mean is that if you don't perfectly know how css and html works, you can't use this framework easly anymore.
The problem is that I don't know if I'm totally missing the point here and I'm losing into a glass of water, or if that's if really a totally different framework.
Here is where I'm asking an opinion from you, and some confrontations.
I'm finding some very good stuff like #Router and all new navigation paradigms and new Mobile First components, but in example I really can't find a rapid way to build a nice look and feel layout without working with css and html.
Easy stuff done with Vaadin 8 looks now for me very hard to understand... like Templates: working with Vaadin 10 Designer is really, really weird.
I hope I'm simply missing the point, and some of you can help me clearing my thoughts.
I share your concerns about Vaadin Flow. Here are some impressions I have gathered in learning about Vaadin 6-14, studying the doc, reading the forums, watching the Vaadin Ltd YouTube videos. While I do not cite technical proof for every point below, this might help you orient to the purpose and new reality of Vaadin Flow.
Web browsers have matured
The years in developing HTML5 are paying off with huge rewards now.
One of the major goals of the leaders of WHATWG was to rewrite the specs from the practical viewpoint of programmers trying to actually build real browsers. As a result, the modern browsers have far more behavior in common than ever before, with far less “quirks”. Web apps nowadays behave much more predictably across the major browsers.
Also, note that the web browser makers have consolidated in their use of engines. Every major browser has abandoned their own engine to use either Apple WebCore/WebKit or its spin-off Blink/Chromium. Even Microsoft has given up on its own browser engine Trident/EdgeHTML, and has switched to Chromium for their line of Microsoft Edge browsers. So Safari, Edge, Chrome, Opera, Brave, Vivaldi, and so on are all using much the same engine now, for much closer behaviors. Only Mozilla Firefox continues to use its own web browser engine, Gecko (except for Firefox for iOS which uses WebKit per Apple policy). So, we are down to two main browser engines: WebKit/Chromium & Gecko.
This means a major burden on the previous versions 6, 7, and 7 of Vaadin, making up for behavior differences between browsers, has greatly eased. Vaadin’s internal design can now work more directly with the web's own HTML/CSS/DOM model without having to create it's own intervening layer of behavior.
CSS
CSS has improved radically in recent years with CSS3 finally getting fleshed-out and widely adopted.
For decades the experts said “don’t use HTML table for layout” yet offered no page layout in CSS except for the anemic float feature. Finally, CSS 3 offers real layout, feature-rich and robust. And more amazingly, apparently the browsers have broadly supported these features with very compatible implementations. These new layout technologies are Flex-box and Grid-layout.
By the way, there will be no “CSS 4”. Each of the functionality areas comprising CSS 3 is now its own project with its own development and versioning. This is explained well in one of the excellent videos by Jen Simmons on YouTube channel LayoutLand though I cannot locate it at the moment.
Flexbox
Arrange items in a 1-dimensional horizontal row or vertical column. Control stretching-shrinking, inbetween-spacing, left-centering-right positioning, and relative aligning including baseline.
See this excellent visual guide and tutorial.
Sound familiar? CSS flex-box provides the same kind of functionality as the Vaadin HorizontalLayout and VerticalLayout classes. Indeed, in Vaadin Flow those classes have been rebuilt to directly use this CSS functionality rather than recreating that behavior within Vaadin. Vaadin Flow has changed its terminology to match that of the CSS standard, such as setExpandRatio becoming setFlexGrow.
See what versions of what browsers support Flexbox.
Grid Layout
Arrange items in a 2-dimensional grid of rows and columns. Features are similar to to arranging data in cells in an HTML table. Contents can be aligned up-down or left-right within the cell. Contents can optionally span across multiple cells. You can control gap-spacing and justification.
See an excellent tutorial by the same CSS-Tricks.com site as mentioned above.
Sound familiar? CSS grid layout provides the same kind of functionality as the GridLayout in previous versions of Vaadin. The GridLayout class in no longer built for Vaadin Flow, but you can get much the same behavior using a Vaadin Div object combined with direct CSS commands.
See what versions of what browsers support CSS Grid.
Roll-your-own AbsoluteLayout
On a related note, CSS now provides for on-the-fly pixel-oriented layout. Again, this seems to be well-supported across browsers in a consistent matter. So in Vaadin Flow, they decided to drop the AbsoluteLayoutwhich provided this ability to layout widgets in a x-y coordinate system.
In place of AbsoluteLayout, you can make your own simple little layout class by extending the new Div component. In that subclass, for any given widget, you can extract the Element object that represents the HTML element for that widget within the rendered web page. With that Element in hand, you can specify the left & top (x-y) coordinates to be respected.
CSS can be updated dynamically now, so you can change positioning around, or add/drop widgets, within this layout dynamically during runtime.
For an example of such a CSS layout subclass of Div, see Replacement for AbsoluteLayout from Vaadin 8 Framework in Vaadin 10 Flow?.
Web Components
The emerging Web Components technologies are a game changer, having replaced GWT. They allow web pages, and web apps, to be assembled as a collection of chunks each with their own little world of HTML, CSS, and DOM. This encapsulated scope lets a chunk be added without affecting the rest of the chunks. For example, no namespace collisions in naming of CSS classes and identifiers.
This has meant a huge re-write of the Vaadin internals. And so we must be patient (or just keep using Vaadin 8), as some parts we rely on in previous Vaadin are gradually added to Flow. See the page in the manual on Components in Vaadin 10 for a comparison of v8 versus v10/11/12 components. This page has been kept up to date. For example MenuBar changed from being unplanned to now being expected in Vaadin 14.
On the downside, some features of previous Vaadin may not appear. But read that page carefully and research. Some parts that Vaadin previously created on its own are now directly represented as now-reliable HTML or CSS features.
Conclusion
Like you, I have mixed feelings about Vaadin Flow.
The recent talk from Vaadin Ltd about “mobile first” is worrisome. That seems tangential from their legacy of building serious business apps, enterprise-style invoice/purchase-order/accruals kinds of apps, “boring” software as I call it (and make my living from), as opposed to startup-of-the-week web app with severe design and wacky interfaces.
Some parts important for enterprise business apps such as menu bars are currently missing with no good workaround. The Web Components technologies are relatively new in the industry, and will likely have some rough edges and problems in these next few years. The nice safe Vaadin-only bubble I enjoyed is now porous, with app development likely to have some need to involve a bit more CSS or other web tech.
On the other hand, it looks like the enterprise/business features may come, either from within Vaadin or from outside as web-components wrapped as Vaadin objects. The Web Components technologies and their various polyfills are not new, and have been worked on seriously for some years by many people, and seem to be workable now. As for CSS or other web tech leaking into Vaadin, I do not minding learning a bit more about these given how robust and well-designed they are now and how that means much more documentation and stability may come with them, with Vaadin not having to re-create features across squirrelly browsers.
And some of that porousness of CSS/HTML leaking-in may be closed where it makes sense and provides convenience to the Vaadin programmer. For example, I noticed in the Vaadin-12 Releases page, there is a new Java API for choosing an alternative built-in component style from Lumo or Material theme for any of the components that have a variant, along with convenient Java constants defined for naming those variants. Ex: primaryButton.addThemeVariants( ButtonVariant.LUMO_PRIMARY ) ;. This alleviates the need to access the inner Element and manipulate CSS.
I believe in the long run, the future for Vaadin is bright. As a server-side stateful application server able to auto-generate web app clients from (for the most part) non-web programming leaves it as an amazing tool in a position with no direct competition (save Xojo Web Edition, using a similar architecture).
Resources
Should you upgrade to Vaadin 14?by Marcus Hellberg 2019-08-21 on Vaadin.com blog
V8 vs. V10 - two maintained Vaadin versions, which one to choose?by Matti Tahvonen 2018-06-13 on Vaadin.com blog
Vaadin 10 keeps the same philosophy of previous versions: Implement the UI with Java. No need to use HTML or JavaScript at all. Vaadin 10 added some support for HTML templates, but it's an optional feature.
This video can help you to understand Vaadin 10: https://www.youtube.com/watch?v=Un8zKzw6twM
The Wikipedia page for Vaadin is also useful: https://en.wikipedia.org/wiki/Vaadin
Read the documentation chapter on migrating from Vaadin 8 to Vaadin 10.
I am an iOS developer with decent experience, After a lot of decsion making, we have coome to a conclusion of using phoneGap for our next project which is suppose to be a multi platform app.
Now the question is what to use with PhoneGap, Sencha and jQuery Mobile?
I visited old posts at SO,Quora and a lot of blogs and came to a conclusion that, jQuery Mobile is good to start and learn but Sencha is much more powerful in terms of controls,MVC on client and extensibility.
I have used jquery,jquery plugins and ExtJS in the past and I am fine with either of their mobile counterparts .
So coming to the point, Our application will be designed by a designer who will not know what we will be using to make the app.
he will give us wireframes of the application and slices for images to put on buttons,tab bars etc.
This is how our standard iOS design process works.
So which of the two frameworks will suit this kind of development style where I will be able to replicate the UI given by the designer.
Coming from iOS, Sencha Touch might be a little closer to what you're used to. Having had a little iOS experience, I feel like ST has a much closer layout system. jQuery Mobile would be best if the implementor is used to building things for the browser.
I think both are equally customizable. Having that said ST provides more built in components and hooks whereas jqm wants you to do more on your own. Both frameworks differ extremely in their approach. Jqm uses a declarative designer friendly approach whereas ST uses an OOP programmer friendly approach.
I am starting out a new project that involves the use of JSF 2.0.
From my initial reading, the Mojarra and Apache Implementation of the
project covers the basic components that you will need.
But I know that user's would seek gui with better presentation such as
panel tab, accordion, slider etc... Currently, there are other implementation that I am seeing, the Primefaces, RichFaces and Icefaces.
But I cant find a good article that discusses which among the three are the best.
I have used Spring MVC before but I use JqueryUI for those widget.
Now that I am into component based framework, I would like to use the best JSF Implementation.
I would like to know metrics such as performance/interoperability/ease of use/support.
Sorry if my question might be vague but I would like to hear comments before I select my JSF Vendor Implementation.
Thanks.
I happily use Primefaces as it is by far the most rich set of open source JSF2 controls out there, but they can be infuriatingly buggy at times. It is best to operate under the assumption that component X will not work correctly in a dialog without heavy tinkering.
I would avoid Primefaces if you operate in a development environment with strict UI design requirements as getting everything exactly the way you would like it to look and operate may not be a possibility.
Further I would avoid Primefaces if you are not comfortable with JSF, HTML, JQuery, JavaScript and CSS as you will need a good bit of JQuery trickery to work around the bugs that crop up.
But on that note, I haven't run into a problem yet that a couple lines of custom Javascript haven't fixed for me, and I have one of the most feature rich applications I have ever wrote in the shortest amount of time.
The speed of development is very fast in this area, and any article gets outdated quickly. I used Primefaces for a new project almost a year ago, because at that time it was the only one that was fully compatible with JSF 2 (both Icefacves and Richfaces have had JSF 2 compatible releases in the meantime).
Primefaces has a lot of powerful components that automatically use AJAX, and even more were added in version 3. Unfortunately this focus on new features led to a lot of bugs, but the developers said they would focus on bugfixing after release 3; I can't say anything about the current status since I left the project after 3 months.
There is one thing against Icefaces: a lot of components and functionality are only available in the Enterprise version, which is commercial, not free (but that might as well be a good thing since you get support etc. if your project can afford it).
Why not play with all three libs for a short time, build a simple project and see how you are getting along with either of them. My personal taste prefers Primefaces, but I haven't tried Richfaces since it turned JSF 2 ready.
I have successfully used JBoss RichFaces on a large online B2B store. RichFaces is a quite good framework for building webapps Web 2.0 style, and have easy to use tags that help you develop features faster.
I do not have any metrics regarding performance between RichFaces and IceFaces/Primefaces, but the ease of development should be approximately the same. All three frameworks have similar components, and they are all working towards more and more logic on the client via JavaScript.
At the current state of the JSF libraries, I am fairly sure that you will be happy with whichever framework your choose. IMO RichFaces and IceFaces are the two frameworks that have been around the longest, and i would put my bet on one of these two. IIRC both frameworks have key developers in the JSF design group as well.
As a general rule of thumb, these framework should work interoperably, but I wouldn't mix and match between them. The frameworks are really ment to be used on their own.
I have been working quite sometime with Blackberry application development but customizing UI and components is something am not very familiar with. I understand that the sublayout, paint, getpreferredWidth, getpreferredHeight methods are to be overridden to customize layouts and components. But still the idea is very vague to me. I am still not able to confidently proceed with the development of UI using these concepts. Can someone explain to me the basics of this? I would like to have a clear understanding from the experts out there.
Best thing to do is look at the source code to the Advanced UI Components that RIM provides, in conjunction with the API documentation.
Besides the obvious differences between JavaScript and Java, what are the relevant differences in using either SmartClient or SmartGWT?
SmartGWT is the GWT wrapper for SmartClient, which, as you say, means that you're able to write your SmartGWT app using java.
From my experience the only difference that matters when you're programming is that the GWT wrapper is a bit more restrictive than using the js components directly. For example, programmatically scrolling a TreeGrid from java is hell, since the body of the underlying table (that you need to get at in order to scroll the blasted thing) is not exposed through SmartGWT, while it of course is easily reachable from js.
Overall I wouldn't base the choice between the js components and the gwt wrapper soley on these differences, but I would look at other factors in your project. Which techniques are you most comfortable with? How much custimization are you planning on doing?
In my case, code maintainability.
We are a Python house. But for client-side code we opt for GWT, initially with GXT, but now with SmartGWT.
We don't like Java, but we don't like JS much more, Order, maintain libraries for several widgets, extends objects to give custom functionality, etc. between doing this in JS or Java, the option was obvious, Java side. We write reusable components here, and now we write very minimal code for client side, only reuse components and use REST to comunicate with ours Python backends.
We know that SmartGWT is more verbose than SmartClient, but, with Netbeans autocompletion (some coleagues here use Eclipse) we have direct access to every method, documented, instead to go to the showcase or google every time that we need to test and try new functionality.
SmartGWT provides you the advantage that you may use powerful editors.
You can debug your own code easily (however it's not very helpful for diving into the smartclient code itself).
You have all the auto completion stuff of eclipse/netbeans at hand. When starting to work with SmartClient/Gwt it helps you find the things you are looking for because the editor can list you classes or the available methods and some basic documentation what the class/method actually does. Saves you a lot of time crawling through the docs
Banang : API's to access ListGrid / TreeGrid body are now exposed in Smart GWT.
We chose to use Javascript (no SmartGWT) ... I prefer it that way, although some of our team members (newer to Javascript) would have preferred the SmartGWT way. Both have their pros and cons :
One of the advantages of using SmartGWT, is that you get to have compile time errors since everything gets compiled first by the Java compiler, before it gets rendered to Javascript.
One of the drawbacks of SmartGWT, is that it doesn't expose the full underlying Javascript Smartclient API. This means, if you want to do more advanced stuff, you might end up needing to do it in Javascript anyways.
Another drawback of SmartGWT, productivity wise, is that every single change you do and want to test, needs to go thru the painful Java EE compile/deploy process, whereas if you do it in Javascript, you can alter client side code faster by changing .js files directly without the need for the whole compile/deploy process.
SmartGWT is based on java code and when compiled it transforms it into java script, is a
heavy since it transforms java code into js
SmartClient is a framework based on js, you can use its components in an xml page and you manipulate them in Js, and it’s light
le showcase de smartclient
I recommend smartClient