I am developing an app in Dart and I plan to support dynamically loaded plugins. I can't do this in mirrors as it does no support instantiating classes from external sources, listing classes from external files etc. Do you plan to extend mirrors to support java like reflections?
Thank you, Skoky.
It was discussed several times but I think it is not decided. What was mentioned as argument against this feature is security which is taken very seriously especially in the browser but of course there are advantages and not having this feature limits the possibilties of Dart.
What you can currently do is launching additional isolates from external code files. This is currently cumbersome in the browser because an isolate in the browser doesn't provide access to not only the DOM but any browser API which is extremely limiting. But as I understand there are improvements planned or maybe already work in progress.
I am looking for Content Management Systems that comply with W3 standards in HTML. I prefer those that are coded in Java or PHP (preferably Java). Any ideas where I can get such information? I checked on http://www.cmsmatrix.org and http://en.wikipedia.org/wiki/List_of_content_management_systems but they don't tell if the CMS's actually comply with W3 standards.
W3C published many standards.
I’d say that most of these standards can be relevant for CMS, e.g., HTML, CSS, RDFa, ATAG, WCAG, WAI-ARIA, etc.
And most of these technologies/standards/best-practices would be implemented in the frontend/backend theme (aka. template). So any CMS which allows you to use custom themes should do the job.
If or which default themes of which CMS follow W3C standards is a question which would be off-topic for Stack Overflow. You already found lists of CMS; select the Java/PHP ones and check their default theme for whichever criteria are relevant to you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We are trying to choose a framework for our client development for a web application. These are the key points about our application.
1) Rich text application where user performs many activities in the client.
2) We are looking to develop using Java technology
3) The services will be offered in cloud.
4) Mobile support is required.
5) Scalability is also one main concern.
I went through lot of doc and information along with this video http://twit.tv/show/floss-weekly/187 online and have now left with Vaadin and plain GWT. I have a small bit of experience in development with GWT, but not in Vaadin(I have written couple of sample programs only in Vaadin). Please help me in understanding few things.
1) If I have to write a new widget in Vaadin how easy or difficult it is to accomplish?
2) Is there any obvious issues with Vaadin widgets or concepts which might be a blocker for any application?
3) If tomorrow we decide to just switch back to GWT, is that feasible given that Vaadin works with all server code logic?
4) Does the Vaadin method of going to server everytime a concern for applications that are deployed on cloud?
5) Last but most important, how is forum support and future dev?
Thanks a lot. Please note that I have gone through many articles and links about these discussions but feel its good to know from a guy who has real experience in these stuffs atleast for sometime. Thanks again.
GWT
now left with Vaadin and plain GWT.
Vaadin 7 and Vaadin 8, now known as Vaadin Framework, are both Java-based wrappers around Google Web Toolkit (GWT).
You write pure Java code for your business logic and UI-creation. This Java code runs in a JVM on the server-side in a Java Servlet web container. The magic happens when Vaadin uses GWT to auto-generate the necessary HTML, CSS, JavaScript, DOM, AJAX, XML & JSON, WebSocket, and Push code needed to render your web-app’s user-interface within the user’s client-side web browser.
So, pure Java on the server-side, pure web-standards tech on the client-side (no Java on client).
Web Components
Vaadin 10, now known as Vaadin Flow, replaces the internal use of GWT with the emerging Web Components standard technology. This new generation is a major re-write of Vaadin, though its purpose and many of its concepts such as data-binding remain the same.
By leveraging Web Components technology, it should be easier to build Vaadin widgets. And it should be relatively easy to make existing JavaScript-based components not designed explicitly for Vaadin available to your server-side Java code. That's the whole point of Web Components: making web-based widgets that work across various web framework tools.
While the Vaadin Ltd in quite excited and proud to ship Vaadin 10 Flow, they remain committed to Vaadin 8 Framework as well. Vaadin 8 is under active development, with a road map plan for continued support at least through the year 2022.
If you really want to work with GWT, you can do so in Vaadin 8 Framework.
If you want to bet on Web Components instead of GWT, go with Vaadin 10 Flow.
Rich apps
Rich text application where user performs many activities in the client.
If you meant "rich text" as in fonts, colors, and such, you should study the RichTextArea widget bundled with Vaadin 8 as well as check the Vaadin Directory for additional add-ons. That widget is not being brought over to Vaadin 10 Flow, but as mentioned above, the use of Web Components may make other existing such tools available to a Java-based Vaadin app. I see one already in beta.
If you meant "rich" in terms of professional-looking, business-oriented, desktop-style web apps with enterprise-level reliability, that is the very purpose of Vaadin.
Java
We are looking to develop using Java technology
That is the raison d’être of Vaadin: Writing pure Java to leverage the vast ecosystem of Java tooling and libraries, with all its benefits of security, performance, and reliability — while at the same time using web-standards technology to auto-render your app in a web browser.
Mobile
Mobile support is required.
The Vaadin collection of widgets have evolved to support touch-surface gestures.
The Vaadin Ltd company previously offered a special package for mobile support, called Vaadin Touch. The built-in support for touch gestures in regular Vaadin widgets rendered that package obsolete and unnecessary.
Cloud & scaling
The services will be offered in cloud.
Scalability is also one main concern.
Your Java-based Vaadin app does live in a JVM on the server-side. Each current user is represented by session object. All the user-interface widgets appearing in the browser have a counterpart in a Java object on the server. You may be keeping further data and functionality in additional Java objects on the server. You may be calling JDBC or Web Services etc. from that server-side as well.
So all of that takes up memory and CPU cycles on the server. You do need to be cognizant of your programming doing caching and placing other burdens on the server. Any resources shared between users must be thread-safe, as a Java Servlet environment is multi-threaded by design.
Robust server hardware (memory, cores) may be needed, depending on the particulars of your app. Or you may want multiple servers with sticky-session load-balancing if you truly have a very large app with very many users.
The Vaadin Ltd company has simulated the use of a Vaadin app supporting thousands of simultaneous user sessions. You can contact them for consultations on your particular situation.
While scalability is an issue to consider, do not jump to conclusions. Think it through, and do some experimentation.
Creating custom widget
If I have to write a new widget in Vaadin how easy or difficult it is to accomplish?
In Vaadin 8, you can indeed create your own widgets. But doing so required learning the use of GWT. Doable, certainly as you can see from the hundreds of published add-ons in the Vaadin Directory. But still some serious work. The Vaadin Ltd. offered training on this.
In Vaadin 10 Flow, the use of Web Components should make the creation of your own widgets much easier. Check out this starter project provided free-of-cost to get you going. See the tutorial, Creating A Simple Component Using the Element API. Key concepts in creating widgets in Vaadin 10 Flow:
Every Vaadin 10 component always maps to one root element in the server-side DOM representation.
The Element API makes it possible to modify the DOM easily from the server side.
Any other issues?
Is there any obvious issues with Vaadin widgets or concepts which might be a blocker for any application?
Not sure what you mean here. I suggest reading through the excellent Vaadin tutorial and manual. It leads you through using all kinds of features in Vaadin.
Having used other rapid application development environments for desktop apps, Vaadin always made sense to me, fit my way of thinking and doing things.
Bleeding edge
For Vaadin Flow, know that Web Components is still new, and somewhat bleeding-edge. Web Components is actually a collection of technologies. Not all of these are supported fully by all browser makers. So some polyfills are still necessary.
Vaadin Flow also makes use of the pair of modern page-layout features that have finally arrived in CSS: Flexbox and Grid Layout.
Only the latest versions of the browsers are coming close to having good support for all these features. See CanIUse.com for particular details.
Part of Vaadin’s purpose is to paper over the gaps between various versions of various browsers, to insulate us developers using Vaadin. So you may not encounter problems in some browsers, but then again you might.
Also, Vaadin Flow does not quite have all of Vaadin 8 features. Some are under development, and some are planned.
Upshot: If you are eager to ship soon and cannot insist on users updating to the latest browsers, use Vaadin 8 rather than Flow.
Leaving Vaadin for GWT
If tomorrow we decide to just switch back to GWT, is that feasible given that Vaadin works with all server code logic?
If you want to use GWT, and you want to write that server-side logic in Java, then Vaadin 8 Framework is the perfect tool for you. I do not see how you would ever want to leave Vaadin.
But if you did leave Vaadin, you would no longer have the glue that connects your GWT in the browser with your Java code on the server. That glue is what Vaadin provides for you. Of course, you can write your Java back-end business logic to be unaware of Vaadin directly. Indeed, Vaadin Ltd provides a Maven-based multi-module archetype for this very purpose. The backend module holds your business logic and database-access (etc.) code, kept separate from the ui module containing your Vaadin-oriented code.
Network traffic
Does the Vaadin method of going to server everytime a concern for applications that are deployed on cloud?
You will need to do some experimenting and profiling to see the memory and cores needed for your particular app. Vaadin can be demanding on server resources as discussed above.
But technically, no tricks or technical limits with cloud deployment. Just plain Java code running, in a JVM. Anything that can run a Java Servlet web container such as Tomcat, Jetty, Glassfish/Payara, WildFly/JBoss, and such can run your Vaadin app.
If you are concerned by the network traffic, yes, there is traffic. When a user uses a widget such as clicking a button or entering data in a field, your server-side Java app is informed so that your app can respond with business logic. So that means frequent network traversal.
You do have options to not immediately inform the server-side when not needed. In doing so, you are controlling some of that traffic. For example, you can choose whether you want the server-side to be informed (and react) for every single keystroke while entering text in a field, or occasionally such as a pause between keystrokes, or only after the user has completed entry in that field. See the [Configuring the Granularity of Value Change Events](https://vaadin.com/docs/v8/framework/components/components-textfield.html section in the manual.
I did fear a problem with Internet performance when I started with Vaadin. But I can say that in my own experience, I was pleasantly surprised, astounded really, to find this was a non-issue for me. For example, in the United States, with a mere Mac mini in a colo in Wisconsin on very fast Internet connection running a Vaadin 7 or 8 app reacts virtually instantaneously on clients accessing household DSL and Cable-TV connections in Seattle, Florida, and Canada. When accessed from Hong Kong, only the slightest delays, generally imperceptible in a data-entry app.
Your mileage may vary, of course. My example above was a dedicated computer. In contrast, cloud providers are notorious for fluctuations in both CPU availability and network delays or latency.
Support
Last but most important, how is forum support and future dev?
Vaadin Ltd appears to be a very healthy open-source company. They sell add-on products, support, consulting, and training. The company has been growing, hiring more staff, and establishing overseas offices (US, Germany) while their home base remains in Finland (Turku, Helsinki).
The various Vaadin products are under very heavy development with many incremental releases, pre-releases, and soon to arrive Long-Term-Support versions. The regularly publish a road map to their development plans. They also provide regular updates on their business and technical issues in their blog.
The Vaadin Ltd company hosts a very active forums site. Both their staff and other users actively use Stack Overflow as well.
I think you should make this decision depending on the architecture of each, because this is the point where they differ the most.
Vaadin follows the Half-Object Pattern and is therefore more comparable to Eclipse RAP (and ZK) than to GWT. You have basically a server-application and you control it from the Browser. Think of a simple Button, its state is hold on the server and in the browser you see a representation of it. Everytime the Button's state changes, it has to communicate with the server in order to update it's state. So this is true for every widget you have.
I must say that I have not much experience with Vaadin or RAP, but imagine how many states your server will have to juggle when you have many widgets and many users who use them at the same time. This may not be a big concern in the cloud, but maybe on a traditional server with limited resources.
That said, you can imagine that this approach is also not very mobile-friendly. Every state-change results in a server round-trip, but on mobile you might have a poor connection or even none at all.
Here I would clearly prefer plain GWT as it can run entirely in the browser and is also usable "offline".
Your other question was about widgets. It is true that GWT does not provide as many widgets as Vaadin, but there are good Widget libraries out there to supplement the stock GWT widgets. The problem is, you can not start with Vaadin and decide later on to switch back to GWT because Widgets written in Vaadin can not be used in plain GWT. But the other way around works, GWT Widgets and self-written widgets are usable in Vaadin.
I would suggest to start with plain GWT, write your own Widgets with UiBinder, it is very very easy. If you feel you would like to use some more complex widgets, look at widget libraries like GWT-Bootstrap or Sencha GXT, they play very nice with plain GWT.
if you want future dev, go with jsf, honestly. It is not the best pick, but you will be at least vulnerable of dying frameworks.
In our project I have to use Vaadin, I would not have decided so. I prefer ZK (http://www.zkoss.org/) or GWT.
Regarding your questions, as far as I can answer them.
Relatively easy, like Swing. You extend CustomComponent and there you go.
Performance. We have performance problems and problems while programming. The architecture had to be rethought several times because of VAADIN specification. In combination with JPA, to me, it is not a pleasure to work with.
Hard to tell. Of course you read everywhere about MVC, loose coupling, etc. But I personally think you always have some roots from your GUI framework that affect some code below. You cannot simply change the framework as plug'n play. I don't know the details, but probably the lifecyle is already different than other frameworks. So the implementation of Vaadin for the communication with the db for example, as when using FormFactory, will affect your persistence layer which you will have to adjust when using another framework. Simply because of the implemented strategy.
I have no experience here.
Vaadin is big in the community and it seems, many people use it. I experienced that the Vaadin team does a string effort in propagating the framework and also is there to answer questions and help you whereever it can. I appreciate that. The documentation is really good.
I personally think you will have to deeply think about the framework and if it does fit your needs.
Before choosing for a big framework think abou, if you want to
- server side programming (ZK, Vaadin, )
- server and client (GWT)
- using markup language and logic (JSF)
What will be your environment setup, like application server, database, etc?
Even though Vaadin is a good product, I would not use it, if I was free to choose.
Ciao
It's better to choose client-side technology like HTML, Javascript or more advanced UI frameworks like ReactJS, Angular instead of server-side technologies. Server-side frameworks are slow in performance and hard to debug for browser issues.
I work for a government science based agency that provides a lot of technical information through our website. Web development is not really our strong suit, but we get by. A lot of our current content is delivered via Java applets. Recently we have had feedback from users that they cannot access various bits of the site, because their browsers (primarily Safari and Firefox) have disabled Java due to security issues. Of course this can be fixed in both cases by upgrading and/or changing preferences but it still raises a barrier that might be too high for non savvy users.
So my question is what is the probable future for Java applets? Is this an approach that is likely to become less common and the proportion of browser configurations that can't/won't run them increase? As I mentioned my organisation (and myself) are not web development experts so we don't have a good sense of the trends. Should new content be written in something other than Java applets (our most recently developed content uses JavaScript instead). Should we plan to convert the applets over in response to diminishing support?
The current trend is pretty clearly toward less support of Java applets in client-side browsers. It never really worked very well and there are now better ways of presenting dynamic information in web sites.
Building a new web site today that relies on a Java applet for content delivery would be a poor technology choice.
Using Java applet for content delivery,as pointed out,is indeed a poor choice of Technology.Modern browsers are capable of doing almost anything applets can offer. Hence,the use of applets have become rather redundant nowadays.
Firefox and Chrome are pushing for JavaScript and Native Client and have disabled Java for political reasons, not security reasons. There where a short period of time where some specific versions of the Java Plugin where a security problem. Apple blocked these versions, while FF and Chrome used it as an excuse to disable it completely.
What technology are best pends entirely on your use case. If development time are the most important factor I would say that Applets using the Swing framework are the way to go. You can use the Swing designer in Netbeans to quickly make GUI:s. Also the performance of a Swing based GUI are superior to that of Flash or HTML+JavaScript.
But keep in mind that browser support will be limited, users will get security questions etc, However if the data you are exposing are sufficiently interesting to the user this would not matter.
If I where to design a startup website that needs to work well in all browsers, fit into search engines etc Applets would be a dead end.
If I where to design a complex website that presents data that are already in demand from an existing userbase, I would go for Java Applets.
As a third option you can do both. Make a simplified website using HTML+JavaScript and a more advanced Applet version using Swing. This would be viable option even for sites that need to be attractive to new users, where some materials would be accessible for search engines and a front page would work in all browsers.
I'm starting work on a smartGWT project in a few days and I'd like to know what kind of experiences you had. To avoid making this a bashing of smartGWT or GWT or a freestyle discussion, I'm going to provide some pointers for the discussion:
Do you feel that the provided widgets are integrated well? Is there any widget you miss in particular?
Have you encountered any problems when designing your application that were caused by the framework?
Is the datasource integration as usefull as the smartClient team claims?
What methods do you use to make your smartGWT application persistent? e.g. How well do Hibernate and smartGWT play with each other?
Feel free to add anything you feel is worth pointing out.
I guess you already have your answers, but I would like to add a few more comments that may affect your decision:
Pros:
SmartGWT is the most compreensive LGPL GWT-based widgetery library you can find. So if you care for GPL pain, this is your thing
Comprehensive Showcase.
Really good performance (just check the Showcase).
Very active community in the forums.
SmartGWT extensions is another important project. For example, it has support for GWT-RPC based communication, which is not possible only with SmartGWT (unless you implement your own integration).
Rapid pace of development from the SmartGWT guys. Just count the number of releases since the SmartGWT project appeared.
Cons:
Besides the Showcase, I sometimes feel the only way to figure out how something works is by asking in the forums. This leads to a spread knowledge base. A community based wiki would be preferable.
Large amount of static files you have to use with your application (the famous 'sc' directory) which might lead to problems if your back-end is in GAE (because of the 1000 files limit).
We used SmartGWT in our last project (duration: 6 months). The following is my personal opinion:
The widgets are really great! The documentation and API is verbose. We would use client-side again.
The server-side integration works, but did not save any development time. Instead we had a lot of problems where we had to find workarounds. Also, because of the new API, no other developer can maintain the project within investing a lot of time to learn the SmartGWT API.
Some Cons:
You have to learn a totally new API instead of using Hibernate and GWT-RPC or REST.
The data integration is done automatically, that is true. But if you need some (also little) changes, you have to write XML mapping files as with Hibernate or JDO. So the benefit is gone.
The forum support is bad: You get an answer to almost every posted question. But that answer often does not help. They ask you things such as “why do you want to do that”. Or they say: “use our tool and do XYZ with it” three times, although again and again I told them this suggestion does not work. After a few answers to a question the final answer is: “you need training, buy our support”.
The commercial support is way to expensive (costs approximately as much as the SmartGWT license).
We will probably not use the server-side integration of SmartGWT again.
You can read all my "lessons learned" with Pros and Cons at my blog:
http://www.kai-waehner.de/blog/2010/12/11/lessons-learned-smartgwt-2-3-component-library-for-google-web-toolkit-gwt/
Best regards,
Kai Wähner
Do you feel that the provided widgets
are integrated well? Is there any
widget you miss in particular?
You could create any missed widgets, there is no single framework that can provide everything you want. The widgets are pretty extendable.
Is the datasource integration as usefull as the smartClient team claims?
The data (JSON/XML) can be provided by servlet services, and they are understood by the
widgets.
What methods do you use to make your smartGWT application persistent? e.g. How well do
Hibernate and smartGWT play with each other?
In the backend servlet services of GWT, you can persist your data in the store by using any persistent layer in Java. Hibernate can be just used as same as normal java app.
Do you feel that the provided widgets are integrated well? Is there any widget you miss in particular?
Yes. The widgets have a consistent API and work well together.
Is the datasource integration as usefull as the smartClient team claims?
This IMO is one of their strongest feature. Once you start using their Datasource API you realize how little code is required to get a fully functional CRUD screen
What methods do you use to make your smartGWT application persistent? e.g. How well do Hibernate and smartGWT play with each other?
Hibernate works out of the box with the SmartGWT EE version. With the LGPL version using Glead works wells
I think SmartGWT has a ton of great widgets, but but but there is a HUGE price.
Create a simple SmartGWT based project and watch how many files get loaded by your page.
That, I think, is totally against the ideals of something like GWT. While SmartGWT may be a pretty good option for people on a deadline, if you want raw performance, stay away from it.
The number of HTTP requests will simply kill your application.
Have you encountered any problems when designing your application that were caused by the framework?
Yes. When I combined Google Eclipse plugin, SmartGWT, GWT 1.6.4, and Wicket the gwt compiler would emit bad javascript. By bad javascript, I mean javascrip that would not work in webkit, or firefox. I was not able to get good javascript until I removed it completely from the Eclipse project and restarted Eclipse. So, this combination would not work and I ended up building the SmartGWT piece separately in another project. The other issue is that the Smart client seems to want control of the whole page in a css sense. So, the integrated SmartGWT module was all messed up, because styles were not isolated properly. Your mileage may vary.
Personally if you use SmartGWT only and for everything then all will most likely be fine, but if you try and mix it, well my results were disastrous. So, I no longer use it.
Just as a counterpoint to the poster above who mentioned troubles with Wicket, the SmartClient forums (forums.smartclient.com) have reports of success integrating SmartGWT with a wide variety of other technologies. This poster's problems sound like 1) a GWT bug causing bad JavaScript and 2) CSS naming conflicts between SmartGWT and Wicket, probably neither framework's fault. All of SmartGWT's style names can be renamed via the skinning system to resolve any such conflict.