I've been searching for an answer to this problem and found a lot of resources on how to build a REST API that supports pagination, sorting, and filtering, using what are considered best practices by each author. The problem lies in the fact that these best practices seem to be subjective and there isn't a standardized way to implement these features.
The best examples of what I'm looking for are this implementation that makes use of Spring Data and a Gist published by someone who found himself on the same situation. The first solution relies on Spring Data JPA, whereas I'm using vanilla JPA, which would make me change my entire logic. The second example seems a bit crude since the author himself states that it doesn't contemplate HATEOAS and links, which are, from what I've gathered, an important part of a modern pagination for REST APIs.
What I can't seem to find is a "plug-and-play" implementation of these concepts, that can be easily integrated with Jersey, even if it means adapting my JPA logic to use its methods.
Surely there are advantages to custom implementations as they can be adapted to each project's specific needs, but they can lead to some pitfalls and end up hurting the API in the long run. It would be really useful to have some kind of annotation that can be injected and parse all the required fields, such as sort, order, page, etc.
Is there a dependency that I can add to my project that doesn't force me to reinvent the wheel?
I'm currently using this configuration that I adapted from the example provided in the question. It's not optimal but it works until I can find a better solution. Hope this helps someone who's in the same situation!
I'm looking for some documentation or examples on how to use the GWT 2.1 Editor framework. Google's documentation is uh, somewhat lacking.
From the limited documentation available, I've been able to glean that editors will (in theory) allow you to more easily bind GUI elements to data models. This will alleviate the very common task of copying data into a TextArea/ListBox/CheckBox, and then replicating the user's changes back to the underlying model (and ultimately the DB).
If it does indeed deliver on this, it will be very welcome. For now, I'm left scratching my head as to how to implement any of it. Any pointers to documentation or examples would be highly appreciated.
A little while ago, when I was in the same situation (not only did the snippets from the Google documentation not work, but they also left out the most basic glue code to make them work), I attempted to write the most basic Editors example project for myself. I learned the editor basics from the DynaTableRf example (which is way too complex to get started with Editors IMO), and put something together.
Let me warn you: It's simple, but it's raw and unpolished, it's just a proof of concept. It's just a zip of my Eclipse project: http://www.mediafire.com/file/nwsohz7ov3cx173/playGwtEditors-02.zip (note: This is the old version for GWT 2.1)
Update
I just updated the project to use GWT 2.3. The old GWT 2.1 bug which I had mentioned in my project is gone now. Here's the new version: http://www.mediafire.com/file/u1yffwuxi441dip/playGwtEditors-03.zip
I've been in the same place for a while, trying to figure out how Editors hook up with the RequestFactory stuff. The DynaTableRF sample in the GWT 2.1.1 release is what finally started making things come together - it's complex, but I think you need a complex app to start seeing the benefits. The code in each step is wonderfully simple - but there are a lot of steps!
Here is another example using Editor Framework with Request Factory hope it helps too.
https://github.com/mgenov/injecting-request-factory
I'm currently working on a web app that makes heavy use of JSF and IceFaces. We've had some discussions of moving to another presentation layer, and I thought I'd take the discussion out into SO and see what the experts think.
I'm curious if anyone could weigh in on the pros and cons of the various Java presentation layer technologies. If you've only worked with one, say why you love it or hate it. If you've worked with several, give your impressions of how they stack up against each other.
Our technologies under consideration are:
IceFaces
JSF (without IceFaces)
GWT (Google Web Toolkit)
Wicket
Tapestry
And if I'm missing anything from my list, let me know.
Thanks!
My opinions are quite heavily biased towards Wicket because I've been using it for a while after tripping over JSP mines far too many times.
Wicket PROs:
True separation of layout and code.
Component based which means high reusability of site elements; For example you can create prettified form with automatic labeling and CSS styles and everything and just by changing it's DAO object in the component's constructor it's completely reusable in another project.
Excellent support for things like Ajax, Portlets and various frameworks in general directly out-of-the-box AND more importantly it doesn't rely on anything else than slf4j/log4j to work, everything's optional!
Wicket CONs:
Development has some confusion about things in general and Wicket generics are a bit of a mess right now although they've been cleaned a lot in 1.4
Some components (like Form.onSubmit()) require extensive subclassing or anonymous method overriding for injecting behaviour easily. This is partly due to Wicket's powerful event-based design but unfortunately it also means it's easy to make a code mess with Wicket.
Random CONs: (that is, I haven't used but these are my opionions and/or things I've heard)
GWT is JavaScript based which sounds stupid to me. Main issue is that it reminds me too much of JSP:s and its autogenerated classes which are horrible.
Tapestry doesn't separate markup and code properly in a manner which could be easily validated between the two which will cause problems in the future.
I've used GWT for a couple small projects. Here are some things I like about it:
It's ajax by default, so I didn't have to make it do ajax, it just came along with using GWT.
It's got good separation of client versus server-side code.
I can unit-test my client code using junit
It lets you built crisp, snappy apps, largely because it's ajax.
Things I don't like:
Some things don't work as expected. For example, I've seen cases where click events didn't fire as expected, so I had to do a workaround.
Auto-deploy to tomcat running in eclipse sometimes just stops working, and I could never figure out why.
The biggest question I'd ask is why are you changing presentation layer? That's a very expensive cost and I can see the benefits of one technology outweighing the others by as much as the cost to change...
In short:
= JSF =
PROS:
component architecture;
many libraries & tools;
somewhat good IDE support
CONS:
heavy weight, both in CPU/memory and learning curve;
when something doesn't work as expected, it's difficult to debug
= WICKET =
PROS:
lightweight;
sensible templating system;
good tutorials;
CONS:
reference documentation is not so well organized and deep as are the tutorials;
development team had some serious difficulties, especially when becoming and incubated project. This lead to confusion on important aspects of the framework, at that time I had to switch to another framework because of this...
What about Stripes?
My pick would be Wicket. Have used it and is gives excellent re-usability. It has one of the most vibrant forum/mailing list. As a question and its gonna be answered in minutes. It has excellent support for AJAX. One of the usual cons attributed to Wicket is the steep learning curve. Well those were one of the old age cons which hold no value anymore now.
JSF: Better stay away from it. Another team which developed a project on JSF is now thinking to shift to Wicket after our success with it.
#Megadix: Like you said the documentation was poor in the beginning, but not any more. There is an excellent book called Wicket in Action written by the developers of Wicket. The sample code provided on the site is also a good place to start and learn
I'd wonder if you a have a service layer that's distinct from the web client, something that the web controllers simply invoke to get their work done.
If you do, the choice of web UI technology can be decoupled from the back end. If it's exposed as a contract first web service, you can have different apps share it. As long as your clients can send and receive XML they can interact with your services. Want to switch to Flex? No worries - point it at the service and render the XML response.
See my comparison of Wicket and Tapestry 5: Difference between Apache Tapestry and Apache Wicket.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Question for all the GWT gurus out there - which is the best GWT widgets library out there? And why?
List based on the answers:
Default
Sencha GXT
Smart GWT
Vaadin
GWT-Bootstrap
GwtBootstrap3
Rocket GWT (inactive)
Tatami (inactive)
ErraiFramework
GWTMaterialDesign
И наконец- новое поколение основанное на JsInterop:
GWT + Polymer Elements
GWT + Polymer
Angular and GWT
GWTMaterialDesign
Do not bind yourself to ANY of these libraries. Use Vanilla GWT to create the structure of your project. In particular, use the MVP pattern and an Event Bus. Please, see google article to know how to best design your client application with GWT: Building MVP apps
After, you can use any widget of these libraries (say a table, or a combobox, a datepicker, etc) and incorporate it to your project. Try to use extended components ONLY if you don't see a way to do it with vanilla GWT. This way you don't tie yourself to these libraries which are ALWAYS a pain when you try to do something that doesn't appear in the demo application, contain many bugs and their support are poor at best.
How to look for widgets should follow this order:
First check GWT Incubator to see if
there's what I'm looking for.
http://code.google.com/p/google-web-toolkit-incubator/
Then, if you are looking for
something "cooler" check GWT Mosaic
http://code.google.com/p/gwt-mosaic/
Careful with other libraries, I've worked with them (and still have nightmares).
Depends on what you mean by "best". Best looking? Best API? Best for extending to your own custom needs?
E.g., I was just evaluating table classes to use in our application. We've been using GWT-Ext, but it has many performance problems for us, and is very hard to get the tables sized the way we need them. I came very close to going with GWT-Mosaic, but decided instead to build off the widgets in the GWT Incubator.
So, why did I make this choice? It seems that too many of the libraries out there come with their own, for lack of a better word, baggage. Either you have to dive whole-hog into some MVC framework (which may not be entirely compatible with the rest of your code base), or you have to adopt someone's new fangled layout system, or you have to live with the fact that you cannot really debug the code (because its just JSNI wrappers).
Don't get me wrong, the GWT Incubator isn't perfect...the widgets there are in some amount of flux. In my case, this was the best choice, though. It gives me good (but definitely not perfect):
API
Extensibility
Look and feel (well, this is kinda weak, but that's what CSS is for.)
So...the answer (for me) is a combination of:
Stock GWT widgets (with lots of custom styling)
GWT Incubator tables
A few home-grown widgets
(I should add: the "baggage" I'm referring to isn't necessarily a bad thing. But, if you just want a widget or two, it can raise the bar on what it takes to just get your work done and how good youe application looks.)
See this component library GWT Bootstrap this is a implementation in gwt of Twitter Bootstrap.
GWT alone is a pretty good library.
I didn't use all of the mentioned ones but can recommend Ext GWT.
I prefer vanilla GWT.
Some of the other APIs look pretty and their showcases really show off the widgets, but I always find that the performance isn't the best....when I say performance I mean more like response time. I hate when an application feels sluggish.
Most of the libraries mentioned are not open source and even worse: are just wrappers on top of a JavaScript library. The power of GWT lies in the fact that the application works on different browsers (because of the code generation for the "big" browsers specifically). These JavaScript underlying libraries can cause lots of problems.
I agree with jgindin GWT Incubator and GWT Mosaic are the best so far.
Not saying it's "the best", but I've been using GWT-Ext at work lately. It's got some pros and cons:
Pros:
Relatively easy to setup and use
Decent sized community behind it
LOTS of examples online, all of which have accompanying code
Good selection of widgets that cover a wide range of functionality
Cons:
Makes assumptions about your data's format and structure that you may not be able to accommodate
Library is just a JSNI wrapper, which makes it harder to debug and extend
Future support and development on the library is uncertain
Some annoying cross-browser issues still exist (especially with layouts)
Search function on their forums is essentially useless. (This is becoming a big pet peeve of mine >_<)
Do NOT use any of them! If you plan to develop a large scale application, you should consider using MVP pattern. The best implementation around is MVP4G framework, it supports GWT code splitting out of box. There are a lot of great examples, you can start with. The most valuable one is Mvp4GModules.
Add the new one: GWT-Bootstrap :)
There isnt a stable release right now, but will have soon.
My experience shows that there are always many problems with 3rd party libraries. The best way - is to use well-known and well-maked technology itself plus your own components. It may take a longer time to write and maintain them, but TCO is always at lower level.
3rd party libraries often can break your plans unexpectedly. And it's hard to find and fix the source of problem.
So I'd suggest to use plain GWT.
I think SmartGWT is fine if you just whant to use the Widgets as they are,
but if you would like to extend or modify the widgets as I do in
the Gxt Scheduler I think that Ext-GWT is a better choice.
for me EXT-GWT (aka GXT) is the best library currently available,I use it in 6 months project,and it helps a lot with many predefined components like grids,trees....
It's beautiful as well
SmartGWT is a good library and it has a lot of examples but the user interface is not that sleek. For user interface Ext GWT is good.
gwt-mosaic's user group doesn't seem very active and I couldn't find a user's manual besides the wiki snippets. gwt-mosaic introduced me to two interesting tools.
1) gwt-mosaic includes a wrapper for Tibco's PageBus which is a publish/subscribe tool for the JS parts of your app (RPC handlers, widget callbacks, widget setters). This is an alternative to gwt's event bus.
2) gwt-mosaic encourages the use of Beans Binding (http://code.google.com/p/gwt-beans-binding/) for binding data to widgets and validating widgets.
smartgwt isn't cheap for the full feature set and support. The jar is too large for appengine unless you remove the theme files you don't use. They invest engineering on the server side too.
I've heard ext-gwt is sluggish and the JS files are large.
The gwt widget incubator looks deprecated. I believe the deluxe grid will be released with the new gwt.
The lack of look-and-feel, binding, and validation standards is hampering the interoperability of widget libraries.
Definitely not SmartGWT. Their framework is bloated and has a very half-baked nature. They have a million widgets, but trying to get them to work for your project is not easy. Datasources complicate the process of managing your data in a very big way, for example, in order to get to data in your datasource, you must use fecth and inspect often. While you can cache the results, it is not always easy to interrogate them.
RPC is another weak and convoluted area. There is contradicting information in the documentation and in the forums. While the documentation will say that you should rarely use a custom operation as part of a ds, they forum will tell you that it's perfectly fine. Learning to use these tools effectively is an uphill climb on the best of days.
They will oversell the product. For example, the charting/analytics package contains graphs... But those graphs won't display negative values or let you manipulate axis labels in any meaningful way. And they openly respond to queries about this on the forum with a "yeah so what" attitude. "We don't plan on adding that to 3.0x even though that's one of our selling points, it's on our road map." When they sold me the package, they never mentioned that I couldn't display negative values. Really? What graph would not need to be able to show negative values? I can think of only one- the one depicting the number of unhappy Isomorphic customers.
Stay away from these guys, and head over to any competitor's site, for example ExtJS, JQuery, heck even quxdoo. There are a few projects out there that are really gaining ground and actually offer a good solution.
Take great caution if you ever evaluate this product. It looks nice, but about two weeks in to the project using it, you'll start seeing what I mean. Widgets are half baked, datasources are extremely over complicated, and just because you paid for forum support, doesn't mean you'll actually get anything other than snide, condescending answers that at first will make you think you missed something. You didn't they're generally very arrogant.
Best of luck, and stay away from this product if you value your development time and maintainability. Oh and one last thing. Look at the MVC example on their web site. It has literally nothing to do with MVC other than the label reads "MVC". They'll try to convince you that such frameworks are for inexperienced developers, and that such a concept has no place in real programming... Kinda like those try catch blocks.
Google's default library is the most powerful library.
Ext GWT adds bells and whistles but apart from that it's similar to Google's.
We're currently liking the GWT Mosaic widgets. We've worked with ext-JS and we've rolled our own widgets in the past. ext-JS licensing and bulk were a problem for us. Rolling our own isn't what we want to do. Mosaic gives us a happy middle ground which we like to think will be an even happier middle ground as the project matures.
I would say if you need only a few widgets then build your own. You might copy-paste some concepts from the libraries mentioned. But they all lack one or the other thing.
I have played with most of them and abandoned every one.
One thing to be aware of is that from the forums GWT-Ext looks like it will no longer be developed/maintained much (maybe not at all?). On their website they recommend migrating to SmartGWT.
Didn't see this one mentioned, Vaadin (previously known is IT Mill Toolkit), but maybe that's because it's not technically exactly GWT; as their FAQ says:
How does this differ from GWT?
GWT applications run in the browser,
while Vaadin applications run on the
server. We do actually use GWT as a
"rendering engine" on the browser
side, so you can combine Vaadin and
GWT.
smartGWT is slow and examples are lacking and it is very hard to find answers for even the basic questions, i.e. see all my non answered questions on this forum.
I'm dumping smartgwt.
Comparison of the two EXTs here with pros and cons.
We have built a large HR portal and a couple of smaller applications using GWT Portlets. The focus of the project is not so much on building a collection of widgets but on creating a simple programming model.
From the website:
GWT Portlets is a free open source web framework for building GWT (Google Web Toolkit) applications. It defines a very simple & productive, yet powerful programming model to build good looking, modular GWT applications.
The programming model is somewhat similar to writing JSR168 portlets for a portal server (Liferay, JBoss Portal etc.). The "portal" is your application built using the GWT Portlets framework as a library. Application functionality is developed as loosely coupled Portlets each with an optional server side DataProvider.
I am using GWT for a year. After lots of research, I have decided GWT Mosaic as a widget library.. Mosaic uses some of the GWT incubator components such as PagingScrollTable.. But the features of the combobox and table are not sufficient for us.. That is why, we have extended these components to add needed functionality.
Check out SpiffyUI: www.spiffyui.org
It is not just a widget library but complex UI/UX GWT framework.
Two important things -and what the most of libraries miss- are unit testing and debugging. It is where GWT shines. If you use a library which is based on vanilla js, you give away the ability to unit test and debug your project. As a GWT developer you should consider these points and use a library with no or minimal js dependency.
We've been doing gwt projects for more than 2 years, and we stick to the default widgets. We made our own open source library to autopopulate the default ones or our own widget extensions. Please check it, it's called gwt-jet. It's very well tested since we use it in large production environments, and we hope it will grow safely thru time.