In my new project client has requested to use GWT/SmartGWT for developing presentation tier. (Note: Screens are not much complex)
I am aware about the MVP Pattern (never used) but I need to decide which flavor of the MVP pattern I should use which meets following criteria.
I should be able to integrate/use SmartGWT components seamlessly with the MVP framework.
It would be great if framework provides me flexibility to support UI to be displayed on Mobile or iPad sort of devices.
I have noticed before that when components of GWT and SmartGWT used together the behavior is inconsistent. Correct me here is it true yet?
Any guidance on this would be highly appreciated.
Thanks!!
Bhavesh
MVP is a pattern Google created for the base GWT widgets, which do not have support for data binding built in. Google has never said that MVP applies to SmartGWT widgets, where the widgets already have support for data binding, and we (Isomorphic) strongly advise against trying to use Google MVP with SmartGWT unless you have very specific, very unusual needs (more on this here:
SmartGWT GWT client server architecture)
When people try to apply MVP to SmartGWT, we see them re-creating functionality that already exists in SmartGWT, making things vastly more complicated than they need to be, and repeatedly looking for APIs and override points that aren't there because they are re-inventing things that are built into the framework. And this experience is not unique to SmartGWT - many of GWT's smartest users are complaining that MVP creates complexity and unneeded code even with the core GWT widgets.
So our advice is: start with the SmartGWT QuickStart Guide, and only look at MVP or other third-party architectural advice when you find a concrete, specific problem SmartGWT clearly doesn't address (still waiting to hear about this :).
It does not play very well together, in fact most widget libraries fail in this area.
It's not impossible, but not there yet.
Yes, SmartGWT is a component library, you'll be using their widgets just like those that come with GWT.
It might work, but don't expect it'd be just like on the desktop (I had some issues with scrolling, but that might have been my mistake, we don't use smartGWT any more)
Regarding the interplay, yes, it's correct, they don't mix well, but in some cases it might work. It's better not to mix. At least that was my experience with SmartGWT 2.2.
Related
I am making a software that will support multiple features simultaneously. I know the logic, and I have developed the features to support.
I want my project to have a look similar to Metro GUI of Windows 8. It need not to be specifically Metro, but similar.
I know about all the layouts in standard Swing library. Currently I am using GroupLayout though. How should I proceed, any ideas? Because the UI seems dull and I don't want to use 3rd party APIs either.
Any suggestions?
I personally would use GridBagLayout, simply because it would allow you to supply better weighted constraints to each "group", but even that might not be entirely suitable.
I would also take a look for the Metro UX guidelines for more ideas
These might be helpful
http://msdn.microsoft.com/en-au/library/windows/apps/hh465403.aspx#tile_design_philosophy
http://blendinsider.com/technical/ux-guidelines-for-metro-style-app-development-2011-10-21/ (look for the section on tiles)
I'm a newcomer to JSF and am still trying to follow examples to learn the basics of how it works, and that has now lead me to begin exploring ICEFaces.
I love the concept behind GWT that you can just write in pure Java and have it compile down to JS and HTML, but I have also heard that ICEFaces offers a lot of things that GWT doesn't.
That led me to start thinking: is there a way to combine the two in a project, and get the best of both worlds? Is it possible to get the AJAX-centricity, rich UIs and underlying capabilities of JSF, but then use GWT to handle all the client-side code generation?
I looked at something called ICEPush which may very well do just this, but without fully understanding the roles both technologies play in MVC web apps I wanted to take a moment and see what the SO community thought of such a hybrid solution.
Having said that, I was wondering if someone could break down - in quasi laymans terms - the intentional difference between these two frameworks, and to give argumentation as to why they can be - or shouldn't be - combined inside the same project.
Essentially I'm looking for an AJAX-friendly, rich UI Java webapp framework that is open source, has an active dev community, and comes loaded decent/good documentation.
Also, not that beggars can be choosers, but I'd appreciate it if answerers don't solicit other solutions besides ICEFaces or GWT. I'm very well aware that these are not the only two webapp frameworks out there, and this question isn't going to convince me to start using either of them; I'm simply interested if their strengths can be combined, or not.
Thanks in advance.
JSF in general makes heavy usage of javascript. JSF or bette the JSF frameworks provide lots of components. The Javascript is generated on the fly.
GWT compiles the Javascript upfront. It provides some components as well. GWT is doing AJAX calls to its interfaces.
I'm not aware of any bridge that allows you to integrate JSF with GWT. So there is no interface and those technologies don't work together.
Both come with good documentation and have an active community.
ICEpush can be used directly with GWT; you can find out more about the integration here:
http://www.icepush.org/product/icepush-GWT.html
ICEpush provides a simple API to "push" notifications to the browser. Essentially, users (or browser windows) are organized into groups. When something interesting happens (such as a new photo uploaded to a photo sharing application) you can invoke a push on the group users.
In the case of the ICEpush GWT integration, you receive a callback into your "Java" code and can respond to the notification (such as, display the new photo). A GWT application can potentially run offline, but that does introduce the risk of application code being subject to offline attack.
In the case of ICEfaces, the ICEpush integration is abstracted away: rather than a "push" to a group, you "render" a group. With ICEfaces you request that all relevant pages be rendered on the server and any necessary page updates are sent to the browser. This makes it particularly easy to add Ajax Push features to an ICEfaces application.
So, the choice is really whether you want to use JSF or GWT. With JSF you have a standard server-side framework that emphasizes pages built from declarative markup. It is the natural successor to JSP application development. With GWT you have a procedural client/server distributed framework that emphasizes events and pages that are built from "Java" objects. It is the natural successor to AWT/Swing on the web. Both are very popular, so it's more a question of the technique you prefer.
I'm working on a client-side Java application for which I want to create a web-based user interface (which will be served up to a browser from the local app). At the risk of oversimplifying, its a microblogging tool that will support functionality similar to Twitter and Facebook. Its open source, and you can read more on our wiki.
Its important that this app is extremely easy to use, and I also want it to look good relative to contemporary web applications (such as the examples available on the Chrome web store). Since I am not a web designer, I'm hoping to use tools that give me an attractive UI "out of the box". Oh, and I need to keep the distributable file reasonably small (un him so whatever I use needs to be reasonably lightweight.
So far, I've looked at Sproutcore and GWT.
Sproutcore apps definite have the appearance I'm hoping for, but I'm not that familiar with JavaScript, and after some experimentation is not entirely clear to me how I will achieve some of the more sophisticated functionality that I think I'm going to need.
Being Java, GWT is more within my comfort zone, however I had a hell of a time just getting my development environment set up properly. It seems that GWT wants to dictate the structure of my application, but since the user interface is only a small part of it I'm not willing to build the entire app around GWT.
Something else I've been thinking about is using CoffeeScript (which seems more palatable him and him him him him him than JavaScript, and there are Maven builders for it), perhaps together with JQuery-UI.
What other options should I consider?
To recommend two big javascript frameworks Sencha and Cappuccino.
These have an extensive UI toolkit out of the box. The latter has an MVC framework build in, the former has a general JavaScript library build in. Both come highly recommended.
Also as recommended jQuery UI is a reasonable toolkit. I would personally couple Sencha for its rich UI toolkit and a lightweight MVC framework like Backbone. I'm afraid this does require learning JavaScript well.
You can also instead drive your JavaScript UI toolkit mainly from the server and skip the clientside MVC. For that sencha should surfice as a UI toolkit, but if you want meaningful functionality you will need some more structure. I would also recommend RequireJS for modular file management.
Take a look on Vaadin its based on GWT but simpler to use. I use it since 2 years and i'am not a designer too.
Take a look at jQuery & jQuery UI (jQuery Modile if you are looking to deploy to hand held devices)
Also, since you mentioned that you are not a designer, you might want to implement the front end in an MVVM pattern to separate the UI from the business logic of your applications. Knockout is a nice way to do with with decelerative data binding
I don't like writing plain JavaScript, so I'll tell you little bit about Java based frameworks. Recently, I've picked Google Web Toolkit.
Pros:
plenty of materials
Eclipse + Google plugin
Very intuitive API
3rd party libraries
Fancy widgets + optimized JavaScript
lot of generics
very active community
awesome async callbacks
Cons:
very slow debugging, that will drive you mad sooner or later
lot of deprecated code for so young framework
Mixed feelings:
You don't have to write declarative UI (you can do Swing-like development), but your code grows bigger and less maintainable, so it is quite probable that you'll eventually learn some declarative UI like UI Binder
Visual designer for GWT is somehow nice, but very unstable (eclipse) :(
Some considerations:
Do some prototyping with Vaadin. Try some debugging. Then try GWT and debugging on similar sized project. Consider debugging as the VERY important decision factor, because GWT debugging was the most frustrating thing for me.
Consider JSF + some nice rich component framework for JSF like RichFaces, IceFaces, PrimeFaces etc (but you app won't be "light" and "small" anymore if you really care). Be sure to be perfectly comfortable with environment (IDE + plugins), nothing beats JSF there (I'd pick RichFaces + Seam today, if full Java EE is option).
If you don't want to learn javascript I recommend you GWT with Sencha-GWT (GXT), you can develop all your app in java language, and also debug your code in java.
It is very easy to create a web app with this technology, and provides almost all funcionality available in javascript version.
Also you can mix it with hibernate and giled to persist your data, and giled helps you to serialize hibernate objects.
I have been writing an application in SproutCore for the front-end and a Java backend. In my mind this works perfectly.
The backend can stop worrying about HTML and JavaScript contents on the client side, if the request is XHR or plain request/response. I can implement the backends using plain old Java Servlets, and only worry about the data that is passed between the client and the server (JSON for the most part).
The client becomed fast and responsive, and SproutCore has a rich amount of components that you can mix and match.
So in other words with SproutCore (and Cappuccino and other full-blows MVC JavaScript frameworks) you can let your client do what it does best : Render and display HTML, CSS and JavaScript, while leaving your server to worry about what it does best: retrieve, store and update data. If you are interested, the source code for this project is available with the GPLv3 licence: https://github.com/joachimhs/EurekaJ
I have written an article about the differnt approaches between server-side MVC and client-side MVC here: http://haagen.name/2011/05/24/The_RIA_MVC_Model.html.
Also SproutCore comes with the MIT licence, so its avaiable for use without (m)any restrictions.
I'm developing a Java ME app & need pointers to some really good UI libraries. I did see a few such as Java ME Polish. Are there any more out there? For e.g. ebuddy's java ME app has an amazing UI and so is gmail's java ME app. What libraries would they have been using or would have they have developed it on their own?
Sun recently released and opensourced their solution to crappy looking lcdui. It is called LIghtweight UI Toolkit and can be found on lwuit.dev.java.net
We have been trying lately on kuix.. So far so good and more light weight than LWUIT
code.http://code.google.com/p/kuix
eSWT would be available for MIDlets on the latest J9 VM, as used by the Series60 3rd Edition feature Pack 2 handsets (Nokia N78, 6210, N96...) but we're mainly talking about nicer looking UI controls. Basically, a MIDlet can look much more like a native application now.
Sun has recently open-sourced LWUIT.That could also be worth a look.
Nothing beats drawing your own images on a Canvas,though. Generic layout managers in any kind of library will only get you so far. You should only look at the available technologies once you have a good idea of how many different kind of screens your application should have and what they look like.
Most of the apps with amazing UIs (Opera Mini, Gmail, any game from an AAA developer) use custom UIs developed in-house. These developers take the task of developing an UI as one more in their projects and give it personality, involving professional graphic designers. Going with a packaged library would quickly accomplish the task but it would make the application look generic and bland (less bland that with the default UI, but still bland and limited).
In short, go with a packaged UI for quick development, but don't expect the level of quality to be near the apps you mentioned.
I'm facing a similar dilemma right now. We're currently using the default, high-level LCDUI framework for the speed of development, but its severely limiting what we can do. I had thought our best option would be to use a third-party UI framework, but I'm now coninced that if we're serious about the application we should write our own. Its like anything in software, if its mission critical to your application you should write it yourself, even if it that means re-inventing the wheel.
Digitalapes has developed a framework for J2ME application development that includes a high level UI library.
The library is lightweight and well documented, you can get have a look at the Gear framework page for more information, or you can directly download the JAR and javadoc from Gear's sourceforge page.
Digitalapes blog includes also a series of tutorial about how to use the framework.
Polish has really nice set of UI components, which are skinable with css style comments.
It also features a device database for compatibility purposes.
Some tipps if you decide to go with polish (as i did):
Use eclipse and the mepose plugin. The netbeans integration is really nerve wracking.
The bulletin board is dead, so by all means !use the mailing list!.
If you are not familiar with the ant building system, you better start now.
The J2ME Polish book is not worth its money. (My opinion). The documentation on their website and the sample coded are enough to give you a solid start.
I've used SWT when deploying to a full profile J2ME (IBM J9 on PocketPC), I don't know if it is usable by MIDlets however. It's quite a nice GUI library in its own way, and far better than AWT.
Unfortunately companies usually end up designing their own GUI's when it comes to mobile development. It's the only way to have full control over your interfaces, but you should consider if it's worth the additional development time, and you're also on your own when it comes to device compatibility issues / handset bugs - of which there are plenty.
If you are happy with a less flexible interface, you can go with one of the existing libraries. I currently use J2ME GUI from http://www.garcer.com/. We get the same flexibility as with desktop development and it also features custom styling, so with a little extra effort you can make it look the way you want it to.
You can use LWUIT for the UI development in J2ME framework.
There are zillions of Java web application frameworks.
95% were designed before the modern era of AJAX/DHTML-based development, and that means these new methods are grafted on rather than designed in.
Has any framework been built from the ground up with e.g. GWT + Extjs in mind?
If not, which framework has adapted best to the world of forms with dynamic numbers of fields and pages that morph client-side?
Echo2 / Echo3 by Nextapp (www.nextapp.com) is totally awesome.
Advantages over GWT:
1) It is not limited to a sub-set of java like GWT
2) It is easier (in my estimation) to learn
3) Has extremely robust design studio for almost drag and drop designing.
4) It is very fast, and works very well on all platforms browsers
5) You can write your application using either java script or java
6) It has great and straight forward methods for handling events and actions.
Personally I think that for any web-application in which you are trying to integrate java and speedy delivery I wouldn't hesitate to pick Echo3 or Echo2.
If you're starting from scratch. I'd have to say Google Web Toolkit. I have to say it is incredibly powerful. You get keep using most of your Java tools. Plus, you don't have to duplicate code that exists on both the server and the client, it just gets compiled differently for each area.
I'd consider REST-style frameworks as well as the other recommendations here- Restlet or Jersey may be good choices for the backend, while you use something like JQuery or GWT on the front end. Both frameworks can easily produce JSON, and the REST style provides a nice clean line of demarcation between your client application and your server source; I find that JSF can make that demarcation pretty muddy.
I use JSF and IceFaces. Although JSF has a few limitations, IceFaces seems to work pretty well and has ironed out a few of the problems with JSF.
I haven't used a really good AJAX Java framework as yet, although Echo2 looks interesting.
I like the stripes framework. It lets you use whatever javascript toolkit you want.
Here is their documentation on AJAX
GWT is quite powerful and easy to use (all Java, no Javascript/HTML/CSS coding). If Google has their way it will be a dominant framework/tool in web applications development, and for good reason. It already works with Google Gears (which allows offline access to web apps) - and more than likely will be optimized to work within Google Chrome.
DWR
I use this to dynamically populate drop downs, and even filter them on the fly based on user input in other places on the form.
I like the combination of JBoss Seam and Richfaces, especially with the JBoss tools that are extentions to Eclipse - makes building these sort of RIA's incredibly easy.
Wikipedia contains some useful comparisons:
Comparison of JavaScript frameworks
List of AJAX Frameworks
Your choice depends on several different factors including whether you want the "work" done client-side (most javascript frameworks) or server-side (echo2 etc.). Other things worth looking at are tools like OpenLaszlo that provide Flash (I think) out of the box, but drop back to DHTML if there is no Flash player present.
Unfortunately I think the decision comes down to balancing several competing cocerns. Check out the comparisons and try them out - most come with online demo's for you to try.
Aptana has a server side frame work called Jaxer. This is from their site:
Jaxer's core engine is based on the same Mozilla engine that you'll find in the popular Mozilla Firefox browser. This means that the execution environment you use on both the client and the server are the same. It's Ajax all the way through and through. That means you only need one set of languages -- the languages that are native to the browser -- to create entire applications.
This framework is open source and has a very nice IDE based on Eclipse. Aptana is also working on a Javascript implementation for ActiveRecord called ActiveRecordJS. Potentially you could use this both client and server side with their framework.
GWT is one of the best AJAX framework that I used ever. Most important thing about this framework is that its maintained by Google. And Everyone know "Who is Google ?"
GWT is used by many products at Google, including Google AdWords and Google
Wallet. It's open source, completely free, and used by thousands of
enthusiastic developers around the world.
GWT provide rich widgets that can be used to built any application. Almost all the widgets they have.
Another important point is GWT is continuously developing and its also have stable release which is very good thing. Another thing Google has also released GWT-Material which is again a very good thing because everyone is moving toward material.
I hope this will help you!!!