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.
Currently we are using GWT Platform with MVP architecture for our UI development.
I could see that we always get an advantage of using SmartGWT or GWT-Ext over GWT Platform because there are many built in components which are hard to write in regular GWT widgets.
I have following questions now to proceed.
1. Can we install GWT-Ext or Smart GWT over regular GWT P project and work? i.e Existing screen functionalities will remain with GWT regular widgets. But new development will be used with either Smart GWT or GWT-Ext. Will there be any conflict or issues in doing this?
2. With Smart GWT or GWT-Ext, can we still follow the same MVP framework like in GWT-Platform or we have a different mechanism for server side calls?
3. We wanted to use free licensing products. So SmartGWT and GWT-Ext are free softwares if I understand. Am I correct?
4. Now with both Smart GWT and GWT-Ext coming into picture, which one should I start using it considering, I will get more good components, faster development, good documentation help and good future for the technology. Now it is very difficult to make a choice of what to use? Please suggest.
In case if you feel, there is something else which is the best compared to these and free, you can suggest that as well.
Thanks in advance.
I will conclude as below with many links, comments on my question. SmartGWT is preferable over GWT-Ext when compared to available widget libraries. Also, GWT-Ext support is not much whereas
SmartGWT has enough support even now. SmartGWT is free to use. Also, we can start using SmartGWT on top of our existing GWT Platform application for our further development. With your above comments, I got to know that its not a good practice to mix GWT and SmartGWT widgets. But we can always start using all SmartGWT widgets for our new UI work. i.e You will have screen both from GWT widgets and SmartGWT widgets(Newer screens). Please confirm if my understanding is correct.
Now I have my last question which is very important - All current server calls are GWT Platform RPC calls - using GWT MVP framework. Service layer is built using GUIC framework. I would like to migrate to SmartGWT with minimal efforts. i.e
Existing GWT Platform screens are kept as it is with GWT - RPC calls to GUICE servlet framework
New development will be done using SmartGWT widgets, but would like to have Restful WS calls to GUICE framework. Even though SmartGWT provides data binding mechanism for better server calls, I may not be interested as we have an intention to convert all client server calls to Restful webservices with JSON. Do we have any issues in this approach where SmartGWT is used for better UI development, but with server calls being implemented using Restful Web services (JSON data format). Can somebody help me on how we can implement this behavior? I want GWT client and service to be independent(Technology independent) and hence would like to go for Restful Webservice approach for client-server communication. If we have any SmartGWT sample with restful webservice call it would be really great.
Related
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.
We are trying to port existing thick client to thin client. We are looking at the different technologies, We are trying out different options. We tried GXT as well as GWT in our sample excercises. Which one do you think we should go ahead with? Are there any other better frameworks?
It's several years I work with GWT (but not GXT). I'm using free version of SmartGWT which is a framework based on a google web toolkit (like GXT).
I personally think if you want (& you have enough reasons) to use GWT, then its a wise choice to use a framework above it such as GXT or SmartGWT or others. This frameworks provide a lot of abilities & ready widgets which make development progress so easy & fun, but they have also their own disadvantages, such as increasing your client side js code size, incompatibility with some browsers, execution overhead which may increase response time a little & so on.
Anyway, beside all weaknesses, I believe that it worth to use them & so I suggest you to USE a GWT-based framework, but before choosing one, take care about these notes:
development community, their activeness & speed of adapting with new releases of JDK, GWT & specially new versions of browsers & availability of samples, resources & discussion forums
the variety of provided widgets & ease of coding for developing new softwares
the ability to customize widgets
the ability to integrating with the other technologies & widgets from other similar frameworks
supported development IDEs
& finally the license & pricing
The decision of framework depends on your requirement.
The factors that may influence to selection of framework may vary based on how large product you are going to develop.
Factores mainly include,
The time for learning.
Supporting libraries/plugins.
Fearures Supported.
Development time.
Support forums.
As I have done some research with GWT and GXT as well.
Time to learn GWT is more.
GXT has more number of widgets.
see this .for performance of GWT vs GXT.
For a commercial and large product deveploment the decision to choose GWT,GXT depands on requirements.
There are lots of other frameworks.
vaadin
dwr
ZK
Apache Click
Apache Wicket
Apache Tapestry 5
Ariba Web
There are many web frameworks available apart from gwt and gxt. There is Vaadin, Dart and many more.
GWT is the foundation of gxt and vaadin. Which technology you want to use depends on your application requirements.
GWT is great in terms of performance but not so good with looks
GXT and Vaadin which are built on GWT provide more rich features, more widgets, good in terms of UI and lags in performance.
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.
I'm coding in PHP since a long time. And since a few days I've been looking for a job in web development.
Apparently they're looking for people who either knows ZEND or Symfony. I don't know either one (although I did work a bit on CodeIgniter).
And I really wanted to get into node.js these days.
So I'm asking you guys, what should I privilege to get a job? I have a feeling Node.js is going to become something really important and demanded, so I'd better get into it before others do...
What do you think? Are there other things out there I should learn? I really don't want to get into RoR since I do PHP.
I know this is a highly contested topic, but node.js is more of a buzzword than anything and it will not be a skill established companies are looking for. Many people have realized that javascript is far too nuanced to efficiently write large-scale applications, and that doesn't change once it's server-side. If you want job prospects, learn a statically-typed, managed language like Java or C#. These are not trendy, and for that reason a lot of people will tell me I'm wrong.
Agree, Node.js and jQuery are going to be the big winners here; for client side development anyway. Also, ensure you're well versed in CSS (especially CSS3) and are familiar with HTML(5) and how all of these work together to make beautiful web apps.
As far as server side development goes, you're really free to choose whatever, after all, it's rare the client ever sees the actual code that makes a WebService run. If you can make a reliable WebService in PHP, sure. C#? Why not? RoR? Java? Python? The more you know, the more marketable you are, and you get exposed to a lot more code. Personally, just because I'm forced into the big business world, C# is what I use almost exclusively, but only because I use it everyday.
If you get super adventurous, go for some understanding of SQL as well. And network setup etc. But that could be out of the scope of a web developer.
I would agree with the Node.js suggestion but would also learn the jQuery and jQuery mobile libraries for JavaScript.
They offer a huge amount of functions to ease web development along with support for HTML5 functionality. The other nice thing about this is you can write mobile web apps using jQuery mobile and support all platforms (iOS, Android, WP) with one app. It won't be native but it can still be a great looking app with a huge amount of functionality.
EDIT: Definitely agree with everything Breland says and in addition I'd like to emphasize that SQLite on the client-side would be something good to learn. It's a really nice feature where you can create a client-side database if you want to persist data that is a too big for a cookie or you can go with a real database.
Unfortunately AFAIK it's only supported on webkit browsers right now (Safari, Chrome, Android, iOS) but it could be good to learn how to use this and also an ORM like persistencejs which is a jQuery plugin that creates an ORM for SQLite and can work on the client or server-side.
These days, a "Web Developer" means something else than what it used to 3 or 4 years ago. That skill set is further split into disciplines now, mainly front-end and back-end. The path you go with will likely be based on what you've been comfortable doing as a PHP developer.
If you've been building PHP apps the "traditional" way and controlling all aspects of your MVC apps through PHP then learning modern PHP frameworks that make that approach easier would be an easy next step.
If you've been building PHP backends that expose business logic through an API or service layer, you can stick to the backend track and learn to do the same in Ruby on Rails (using something like rails-api) or Node.js if you wish. If you go the node.js route, picking up CoffeeScript will make writing your JavaScript a little more comfortable but it's another syntax you'll have to learn.
If you've done both 1 and 2 above and you like client side development, learn modern Javascript web development. Don't worry too much about which framework to side with yet, just learn the modern way of building large JS apps. A book I recommend for that is JavaScript Web Applications by Alex McCaw (http://shop.oreilly.com/product/0636920018421.do). It did wonders to help me shed my dislike of JavaScript which came from working with the language many moons ago.
My advice would be to learn both sides of the fence and master one or two frameworks on each side. That will make you what's now called a "full stack" developer, which is just a term used to identify those who are effective at client and backend dev thereby making them highly desirable in the marketplace.
Good luck.
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 9 years ago.
My team and I are beginning to plan the development of a modular application which will likely multi-target WPF & Silverlight.
I personally have some experience using the older version of PRISM to build a composite Silverlight app using the MVVM pattern. We weren't familiar with MEF at the time for handling the various module dependencies, so we didn't use it.
We aren't married to any particular framework, but want to use one of the bigger players out there. As such we've begun to examine Caliburn/Caliburn Micro, Prism, MVVM Light and Reactive UI.
Most of what I've read for modularity suggests PRISM and MEF to handle that part of the process. As I'm still wrapping my head around some of this, I'm not sure if I'm missing some obvious options. I was able to find this article on Caliburn Micro and MEF.
Can anyone point me to similar articles using some of the other frameworks to compose a composite app similarly to the way PRSIM uses Regions, etc? Ideally, I'd like to limit the number of frameworks needed while providing maximum flexibility. We aren't averse to taking a "best of breed" approach and using for example MEF/PRISM to handle the compositing and MVVM Light for the View management, etc; but why use 2 when 1 will do?
One thing you should probably do first is isolate these into their appropriate buckets. I see this a lot where people will mix MVVM frameworks with application composition frameworks. Once you have them in the appropriate buckets you can start to pick one framework from each category and combine them into what you consider to be the best scenario.
Application Composition
Prism (using any IoC container: MEF, Unity, Ninject, Autofac, etc. There are a few things that make MVVM easier with Prism, but I wouldn't call it a fully featured MVVM framework... it's primarily a modular application composition framwork.)
MEF (MEF is actually able to do application composition out of the box. It's often dismissed as just an IoC framework, but it is deceptively powerful.)
MVVM Frameworks
ReactiveUI (my favorite)
Caliburn
Caliburn Micro
MVVM Light
This will help you make a decision, I think. You can pick and application composition technology you like and an MVVM framework you like and be off and running to the races.
As for articles, I don't have too many. There are a lot of good articles on application composition with Prism (that's pretty much its job), but here is a good article on application composition with MEF by itself:
http://blogs.microsoft.co.il/blogs/tomershamam/archive/2009/08/11/wpf-mef-declarative-composite-ui.aspx
You should also check out Glenn Block's series "Building HelloMEF" on his blog. I couldn't find a comprehensive list (he wasn't consistent with his tagging), but here is the "MEF" tag. Lots of good stuff here:
http://blogs.msdn.com/b/gblock/archive/tags/mef/default.aspx?PageIndex=1
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.
I am developing a gwt project and am looking for an appropriate server side technology.
it should support be open source and support user login (and not using openID...) with password recovery etc
it seems that the de-facto standard would be spring + hibernate. however, I am unfamiliar with neither of them and understand that the learning curve (especially for spring) is very high. gwt was quite easy to learn using GOOG's excellent online tutorials but the spring equivalent seem to impose lots of configuration files and deeper understanding of its internals.
so I am looking for a simpler server side technology to deploy my gwt app. I am definitely prepared to learn a new framework if necessary but not something that would take me 2 months just to understand the fundamentals...
any ideas...?
Spring Roo should get you started with a GWT app in no time. It even has scaffoling (like Rails) for easily generating code for views and models. Here is a good video that introduces Roo and here is a guide for the mandentory 10 minutes application that Rails pioneered years ago.
Also a cool thing about Roo is that it gets you started quickly while still doing everything correctly (i.e. integrate with Spring security, Hibernate, Maven, ...).
Edit: You could also try Vaadin (tutorial here) although I am unsure if that may be to simplistic for your needs.
You could have a look at Google AppEngine + GWT. It provides you a full development environment:
http://code.google.com/webtoolkit/doc/latest/tutorial/appengine.html
This post also provides some information on how to get started with Google Plugin for Eclipse, which supports GWT, Google AppEngine, etc.
I second using Google App Engine, especially the Java version as it integrates so easily with GWT. I am using it in this way right now. App Engine has well written and complete docs, similar to those of GWT.
A simple way to integrate the build processes is to (1) use the GWT code generator to generate the standard project tree and ant build process and then (2) read this article on integrating GAE/Java with GWT:
https://developers.google.com/web-toolkit/doc/latest/tutorial/appengine
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.
What is the best way to test GWT code?
GWTTestCase in hosted mode is too slow and none of the mocking frameworks work.
Currently we are following MVC as suggested in http://robvanmaris.jteam.nl/2008/03/09/test-driven-development-for-gwt-ui-code/ and using GWTMockUtilities disarm() and restore() to mock widgets. And we havent figured out a way to test View in GWT MVC. Is there a better way to test GWT code?
If you're looking to test GWT widgets in isolation, there aren't many options. You can use a GWTTestCase to instantiate your widgets and test it through its API, which is what Google does for the GWT widgets themselves: Source for RadioButtonTest
However, the event-firing mechanism doesn't work in GWTTestCases, which means you can't do things like programmatically click a button and expect some onClick() callback method to be invoked on a listener. It also is hard if not impossible to get at the underlying DOM, so it may not be the best tool for testing low-level HTML-emitting code.
It sounds like you are following all the right steps; Rob's article provides an excellent description of how to write testable code using the Model-View-Presenter (MVP) design pattern. The more logic you keep out of the view layer, the better. When that's not possible, use a tool like Selenium to create focused tests of dynamic UI behavior.
I followed a similar strategy - MVP with minimal code in the widgets. In a few cases I did write some code which would wrap the Grid class, so I was able to instantiate my component in a GWTTestCase, pass it a Grid, invoke some methods on my component, and check the state of the Grid. I wrote an article for Better Software about Test-First GWT, which you can read on my blog.
If you're looking to test code that uses non-UI GWT classes (such as URL encoding or Dictionaries), you'll need to use GWTTestCase, or else follow similar wrapping strategies until the code is too simple to break. Then use an integration test with a tool like Selenium, or a few targeted GWTTestCases which only test that you're using the library correctly -- as J.B. Rainsberger says, "Don't test the framework!"
As an alernative, you should try gwt-test-utils, which manage to run GWT client code in a standalone JVM and provides some feature to Mock anything you want (component, RPC services, etc..)
What worked for me:
Use classical model/view/controller (e.g. no business logic in the view or controller; controllers only translate view events into method calls on the model).
Decouple the model and controller code from the GWT view widgets and any other classes that rely on GWT and can't be instantiated in a plain old JVM. You can then test them with good old JUnit.
Write end-to-end tests to test the system through the GUI to ensure that the models and controllers are hooked up to the views correctly. We found it faster to deploy and start up the app and then interact with it through a browser controlled from JUnit with WebDriver than to use GWTTestCase!
Use JMock to test asynchronous calls like this: http://www.jmock.org/gwt.html.
Also have a read at Testing Methodologies Using Google Web Toolkit