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
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 :
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).
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 :
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 .
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
Yeah, extending in ZK can made the same way. It is necessary to change lang-addon.xml only when you want to assing a new name to your new component for use in ZUL files. If you watn to create a component in the Java code (new MyGreatTextField(…)), you can use it right away. But me, and I guess 99% of programmers in ZK, do use ZUL (or JSP with ZK tags) way of creating ZK components - such a big advantage is that.
BTW. check the Vaadin tutorial at http://vaadin.com/tutorial Does the screenshot bellow match the code on the web page? It is hard to say, you have to analyse the code. If you make a proper ZK MVC design of the application, you can pretty well guess just from the first look on the ZUL how the resulting page would look like.
In the context of UI, extending XML or ‘proprietary XML’ is like polishing dirt: XML is the wrong tool for creating UI. The purpose of XML is to facilitate the transportation of data across platforms, operating systems etc. Just because you could use it to declare UI Components doesn’t mean it should be used for that purpose.
Don’t forget that using XML would require reading additional XML file(s), used as the datasource, before converting it to create the UI, but as we know this is a very slow process, which is yet another reason why XML is inappropriate for UI development; not to mention the contrasting structures of XML document and UI design.
XML is more integration overheads: Integration increases complexity and as one who has used jsp, jsf, adf, trinidad, richfaces, icefaces, jsf, flex, apache pivot etc; I now have less headache since I decided to use Vaadin. Obviously, Vaadin is not perfect but why use ZUL, extend ZUL, XML and java when you could achieve a better result with just java: easier to debug, fewer third-party libraries with their own integration problems.
If [repeat:if]
the reason for using XML were because of one’s lack of java knowledge, then I would suggest that any of the jsf frameworks would be preferable. XML is just not the right tool for UI, and I know a few developers who are put off by frameworks like apache Pivot, ZK, JavaFX – I understand that the new JavaFX will now be pure java.
What’s the result of Vaadin? XHTML, i.e. XML. So if you think XML is the wrong tool for creating UI then you probably think all the idea behind web application is wrong. I have heard such opinions already. Usually people who likes the old good desktop application programming says that. Well, good on you. So you are happy with Vaadin, GWT, Flex because you do not need to mess with XHML, CSS and Javascript.
I like XHTML, CSS and Javascript, I like making web applications. ZUL files in ZK give me an option to easily adjust ZK components with CSS and Javascript, mix it with XHTML. I like to mess with this. And many other people like it, too. And, I [repeat]
the ZUL files are just optional. If you like, you can program ZK applications just in Java code, like Vaadin.
As a matter of fact, I do and as you might have noticed, desktop is the direction web application is heading – with Flex and the (new) JavaFX leading the way.
In our business, it is the user that comes first. You can say that on the one hand, we spoil the user by providing them with the desktop experience and on the other hand we force upon them the primitive web pages created with legacy languages like XHTML, CSS and Javascript that are kept being recycled and repurposed. So there you have it.
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 ?