See the widgets and demos in
http://Vaadin.com/directory
Yes. Just install it from eclipse marketplace or from vaadin directory today.
my thoughts on vaadin vs smartgwt :
- vaadin has a 300page high quality manual right there for your developers to start with. This documentation alone will enable your developers to build very solid apps. I did not find the same quality documentation for smartgwt, but maybe it is in their commercial offering that is being referred to so often from their site.
- vaadin is an evolution of 10 years of work and this clearly shows in their API and component model. It has a clean design, responsibility and focus and a very consistent ‘no suprises’ policy. Keeping a product going and its backing company profitable for such a long time counts towards a lot in my book, it is certainly reassuring and gives a ‘these guys really know what they are doing’ feeling.
- In smartgwt i get the idea that the api is rushed and just a thin bridge over the underlying javascript library with little added framework value. It just allows you to do whatever the js lib can do, coated with some java syntactic sugar. Also you never really get away from the js/html side (methods like getInnerHtml(), getDOM(), getJsObj) which opens the door for all sorts of black magic hackery that becomes unmaintainable over time. I want my framework to be a framework and add a useful and just-enough flexible abstraction, Vaadin does that.
- Vaadin could do with more widgets. They should just hire a widget developer for a year and bring the framework more or less in line with nowadays ‘rich and fancy widget’ market, so that this becomes less of an argument in comparisons because it is the first thing users complain about. Not that many people will actually end up using any of those fancy spreadsheet widgets though (for this they will just use excel
just my 0.05€,
Jorg (30 days Vaadin user)
[quote=Joonas Lehtinen]
Yes, i had already looked every pages of that space 
but in the context of the comparison, subject of this thread, i would say that community add-ons are a great added value for a product but are not basically the strengh of the product. That’s why, to my mind, we can’t compare whatever zk, smartgwt versus vaadin + community addons.
In more details : for more than one reason, i’m glad Vaadin has a successful add-on directory around a community contribution, that’s something quite usual in php frameworks but not so usual in java frameworks, so that’s an advantage over smartgwt or even zk for which such a space is not very much formalized and everything is almost in the package.
On the other side, i would not compare community work over what is included into the related product in the first place for many reasons :
-
whatever the product (framework, cms, dms,…), i can’t remember a community place where the contributions status like experimental, alpha, beta… were not in majority over stable contributions. I even don’t talk about certified status :V
-
community add-ons are very unusually backup by a company. Most often, the nice person behind an add-on either stop before the add-on reach an interesting status or finally does not maintain it. :kid:
-
when i mention “maintenance”, i mean maintenance over the releases of the underlying product… Depending of the add-on nature, some addons are not really reasonable to be found in a community directory instead of the product itself. For example, building a cms with the help of Vaadin, i can tell you that i would be far more confident to see ckeditor support into Vaddin itself instead of the community add-on. Another example : when we have no other solution, that’s cool to see an add-on bringing push capabilities but that’s far more cool to see it in the core. There are add-on nature which correspond perfectly to an add-on directory, i don’t see my 2 examples fitting the situation.
I see community add-ons as an added value, not a replacement
13 of those
160+ add-ons in the Directory
are offered and maintained by Vaadin Ltd. They are add-ons mostly because we don’t want to bloat the core.
We’re also very interested in what kind of component our users need and want, so please let us know if you have ideas. The best way to suggest ideas to us is to create a ticket about it
in the Trac
(free registration required). That way the discussion stays in one place, though you could also link a ticket here in the forum for added visibility.
Also, if you are a Vaadin Pro Account subscriber you can
vote
for the ticket
How would adding more widgets bloat the core ? Would it take longer to initialize and load a new application in the browser if Vaadin had let’s say 1000 widgets in the core then if it only had 100 ? (even if the application just uses 10 widgets?) … My guess is not and i hope i’m not wrong. Unless you mean that adding new widgets inevitably means adding new features in the core to support the creation and features of those widgets, then yes i can see the core getting bloated.
Jorg
Hmmm… that’s interesting. We need to pay Vaadin to have the right to vote.
On the other hand, how can we make sure our request will be implemented? Do we need to pay more?
http://vaadin.com/feature-voting
Take top rank 1 (
Ticket#6283
) request as an example.
It was opened 3 months ago but still not closed yet even though it’s voted as Top 1 priority.
Development of Vaadin is funded by services sold by Vaadin Ltd., and purchasing a project to implement a feature has been possible for years. (eg. see
this
regarding third-party add-ons).
The Pro Account was only recently launched, and those tickets are older than the Pro Account itself.
We do listen to all of our users for feedback as ideas, as we have always done, but this new mechanism gives a more direct way for users committed to Vaadin to influence our roadmap.
The Pro Account subscribers can also
prioritize a bug in Vaadin
to actually force us to fix it ASAP. For all bugs prioritized this way by customers we guarantee that they will be assigned to our R&D within 2 business days.
A Pro Account also includes:
- Licenses for all Vaadin Pro Add-ons
- Access to our Knowledge Base that includes hundreds of curated articles about various aspects and best practices of Vaadin
- The inclusion to our security alerts mailing list
- Access to regression-tested custom builds that allows you to get new features and fixes faster than waiting for the next release
- A support request system allowing the user to easily purchase almost any work from the Vaadin team
For further information and pricing see the
Vaadin Pro Account page
or contact us at
proaccount@vaadin.com
.
Can I subscribe Vaadin Pro for just one month and then use the Vaadin Pro add-ons features/components (such as JPAContainer, timeline, calendar, etc.) forever? Is it ok that I just subscribe Pro account one month again when I need the updated version?
Does it include technical support (not just for bugs)? What’s the guaranteed resolved time? Your guarantee in the time of job assignment is not enough for me.
No, the license is valid only while the subscription is active.
If this is unacceptable you can always purchase separate licenses for the add-ons you want to use. They are paid once and valid forever.
I’m afraid that guaranteeing a resolved time is impossible, since it depends on the scope of the issue. However, we are committed to delivering the fixes ASAP, which means that the Vaadin R&D team will start working on the issue immediately.
The Pro Account also includes generic technical support in the form of support requests, but the subscription price does not include support time. Support time is purchased separately, so you only pay for what you use. See more info on the support request system
here
.
Well, good idea but that split interests and opinions around “users” and “dev” with different considerations and conclusions; or the ticket should also mention back a link to the forum for each idea but that will become a little complicated to follow :). Anyway, i don’t see a suited forum category for hosting this feedback, maybe you could create an adapted one ?
To make things quick & easy to undersand, i will rely on competitor examples and to be realistic, i won’t ask for monster widgets (grid, calendar, pivot …) neither asking 100+ widgets :). So here are the more “simple” useful components for which i would like to see improvements on 6 of them and the creation of a new one :
Very nice suggestions, thanks! Some of the use cases are already supported, but you listed several useful and valid improvements.
Pro Account subscribers, if you want to vote for the suggestions, please create separate tickets for each individual improvement and vote for those.
Actually I already split most of the enhancements out to separate tickets to make them more manageable. So even easier for you to vote
That means I cannot continue developing my application with Vaadin after I stop the subscription, right?
Can I continue selling my application to my customers when my subscription is not active?
Can my customers use my application after my Vaadin license is not valid?
Right.
Yes.
Yes.
In many cases you might have more people working on the application in development time than when it is maintenance. Thus you might want to get subscription for the development phase and end it when the application moves to the maintenance phase. For example, say you are implementing Product 1.0 with a team of 5 developers. The application development project takes 6 months. After the project, you keep only one developer in the project to maintain it and implement minor additional features. In such case, you could subscribe all 5 to pro account for 6 months. When the application is done you can either keep the maintainers pro account subscription or purchase the used add-on licenses (for the maintainer).
What really important to me is, is how extensible a component is. Its all very well to declare your GUI component in XML like this :
<MyPanel>
<MyTable/>
<Button1/><Button2/>
</MyPanel>
But what if you want to use that MyPanel as a generic class? What if you want to create a subclass with different buttons for different users? How would you do that in XML?
That’s the main problem I have with ZK, or for that matter, all XML declared UI languages. In that sense Vaadin sounds like the better option.
Out of curiosity, I have two components that I made in Swing on my blog :
http://blue-walrus.com/?p=253
http://blue-walrus.com/?p=173
Would create components similiar in Vaadin? Would the code look similar? Would creating them in ZK be just as easy, or will you end up in XML/javascript hell?
Extending components in ZK is very simple. You define it in the lang-addon.xml file, check the ZK documentation. E.g. if you have a component, you may extend it and use the same name (so you override the original component) or you can use a new name . Furthermore, you can use your new component in the ZK Studio Visual Builder. Adding an attribute the your new ZK component is also very very simple - just make a getter and setter in your class. So you can have .
Extending components in Vaadin:
public class MyGreatTextField extends TextField {
// My great improvements
} Now MyGreatTextField can be used in my code, used in Visual Editor or packaged as an add-on.
Cool, we should mix the 2 frameworks as we have support for both of them in the same forum 
Joonas, your explanation about licensing above is interesting, that’s a fair way of managing licence across development and maintenance phase
Ok, i will take attention for following this rule in the future.
I forgot to propose a widget, visually simple but a nice one like i love widgets to be : simples but effectives