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.
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 company is planning on developing a brand new web front-end application.
Some background:
It must "sizzle" i.e. a nice marketable look and feel.
Our development team has no Java experience, with limited experience in Silverlight, Javascript, JQuery or CSS.
Time to market is a factor.
We need to stream large amounts of data from an Oracle database.
It must support 500 - 1000 concurrent users
It will be hosted internally behind a firewall.
We need mapping (geo-spatial) capabilities.
Someone has recommended using GWT instead of Silverlight or Traditional technologies(Javascript, jquery, CSS etc.).
I am not sure if this is the right way to go? A lot of the GWT news is from 2007/2008. It makes me think that this technology is old and maybe dying.
If you had a choice would you choose GWT?
unfortunately two of your statements are mutually exclusive in this context:
Our development team has no Java experience
Time to market is a factor
I'm a Java programmer who has picked up GWT over the last year or so. It's immensely effective being able to write direct to the browser using a compiled language & mature development tools. I can fly through web-development faster than ever before (using ASP, JSP, ExtJS ...).
But, as the other commenters have said: if you've no Java experience you're going to find it a real challenge picking up both technologies (Java & GWT) in a short time. If you do manage to make it to market in a reasonable time I could only imagine the code base would be in very poor condition (since you'd be learning as you go) - which would be a very poor foundation for your organisation's shiny new venture.
There again, you don't have a 'lot' of skills in the other related skills you listed either.
I suspect there's a more effective solution. As some wise old goat project manager said:
I have three variables to delivering your project: time, cost and quality. Pick any two
In your situation, if the organisation wants a quality product in a short time, it's the cost factor that must compensate - your organisation should buy in some interim GWT expertise to give you a sound software architecture and to mentor your team for the next few months. After that you'll be ready to take the reigns, inheriting a quality codebase by 'standing on the shoulders of giants'.
As others have said, GWT definitely is not a dying project. Quite the contrary actually as there are now more than 20 regular contributors from within Google (versus a semi-dozen back in 2008). Wave (despite being discontinued as a Google service, it's still alive as an Apache Foundation project), Orkut, AdWords, Google Moderator and the new (still beta) Google Groups are made with GWT; and parts of Google Buzz and a few other projects at Google are built with it too.
Now as to your choice:
Silverlight is a dying technology. Microsoft made it clear that it now invests in "HTML5": http://www.zdnet.com/blog/microsoft/microsoft-our-strategy-with-silverlight-has-shifted/7834
GWT is mostly a client-side toolkit, but it comes with "high productivity" tools for client-server communications (GWT-RPC and RequestFactory for end-to-end protocols, AutoBeans for easy JSON serialization). With UiBinder, you can easily put to use your web designer skills.
if you're comfortable with JS, then go for it, but then you'd have to choose the "right toolkit" (jQuery? Google Closure?). Otherwise (which seems to be the case), it really depends how much "ajaxy" you need/want to be. I'm a strong believer in "one-page apps", but YMMV, or you can have specific constraints that rule it out. In any case, you'd have to choose a server-side technology.
So, depending on your needs/wants and skills, I'd choose GWT or "some JS toolkit". In any case, you'll have full control over the look and feel (unless you choose one of the bloated players: ExtJS/ExtGWT, SmartGWT or similar; you'll probably have a shorter time-to-market with these, but you'll pay it later, in terms of performance, integration with other toolkits, and look-and-feel).
In the light of what you're saying about your skills, I would definitely recommend GWT (despite your lack of experience with Java); because lack of experience with JavaScript is far worse than lack of experience with Java (you're talking about a "large application", so it's really important to start building things right and/or have tools to help refactoring, which you'll have with Java).
#ianmayo replied while I was writing the above, and I can only second what he said!
GWT is definitely not old or dying! A lot of Google's own applications are developed using GWT. You can download the GBST case study and learn how the global financial company uses GWT to improve productivity and create a rich user experience. You have to know that when you use GWT you automatically use javascript, html, etc. You create a your gwt application in java, but when you compile it gwt creates a folder with html files, javascript code, css, etc...
I definitely recommend it!
In order not to mislead readers with above seemingly unanimous answers, keep objective view in respected stackoverflow, following review expressed exact experiences I had with using GWT. Whether GWT is dying depends on how many new apps will adopt it,Google trend can tell (gwt trend).
Excerpt from https://softwareengineering.stackexchange.com/questions/38441/when-not-to-use-google-web-toolkit
>
I am both good and bad to answer this question - good, in that I've actually used it before, and bad, in that I was quite experienced with HTML/CSS/JavaScript prior to working with GWT. This left me maddened by using GWT in a way that other Java developers who don't really know DHTML may not have been.
GWT does what it says - it abstracts JavaScript and to some degree HTML into Java. To many developers, this sounds brilliant. However, we know, as Jeff Atwood puts it, all abstractions are failed abstractions (worth a read if considering GWT). With GWT, this specifically introduces the following problems:
Using HTML in GWT sucks.
As I said it, to some degree, even abstracts away HTML. It sounds good to a Java developer. But it's not. HTML is a document markup format. If you wanted to create Java objects to define a document, you would not use document markup elements. It is maddeningly verbose. It is also not controlled enough. In HTML there is essentially one way to write
<p>Hello how are <b>you</b>?</p>
In GWT, you have 3 child nodes (text, B, text) attached to a P node. You can either create the P first, or create the child nodes first. One of the child nodes might be the return result of a function. After a few months of development with many developers, trying to decipher what your HTML document looks like by tracing your GWT code is a headache-inducing process.
In the end, the team decided that maybe using HTMLPanel for all HTML was the right way to go. Now, you've lost many of GWT's advantages of having elements readily available to Java code to bind easily for data.
Using CSS in GWT sucks.
By attachment to HTML abstraction, this means that the way you have to use CSS is also different. It might have improved since I last used GWT (about 9 months ago), but at the time, CSS support was a mess. Because of the way GWT makes you create HTML, you often have levels of nodes that you didn't know were injected (any CSS dev knows how this can dramatically affect rendering). There were too many ways to embed or link CSS, resulting in a confusing mess of namespaces. On top of that you had the sprite support, which again sounds nice, but actually mutated your CSS and we had problems with it writing properties which we then had to explicitly overwrite later, or in some cases, thwarted our attempts to match our hand-coded CSS and having to just redesign it in ways that GWT didn't screw it up.
Union of problems, intersection of benefits
Any languages is going to have it's own set of problems and benefits. Whether you use it is a weighted formula based on those. When you have an abstraction, what you get is a union of all the problems, and an intersection of the benefits. JavaScript has it's problems, and is commonly derided among server-side engineers, but it also has quite a few features that are helpful for rapid web development. Think closures, syntax shorthand, ad-hoc objects, all of the stuff done by Jquery (like DOM querying by CSS selector). Now forget about using it in GWT!
Separation of concerns
We all know that as the size of a project grows, having good separation of concerns is critical. One of the most important is the separation between display and processing. GWT made this really hard. Probably not impossible, but the team I was on never came up with a good solution, and even when we thought we had, we always had one leaking into the other.
Desktop != Web
As #Berin Loritsch posted in the comments, the model or mindset GWT is built for is living applications, where a program has a living display tightly coupled with a processing engine. This sounds good because that's what so many feel the web is lacking. But there are two problems: A) The web is built on HTTP and this is inherently different. As I mentioned above, the technologies built on HTTP - HTML, CSS, even resource-loading and caching (images, etc.), have been built for that platform. B) Java developers who have been working on the web do not easily switch to this desktop-application mindset. Architecture in this world is an entirely different discipline. Flex developers would probably be more suited to GWT than Java web developers.
In conclusion...
GWT is capable of producing quick-and-dirty AJAX applications quite easily using just Java. If quick-and-dirty doesn't sound like what you want, don't use it. The company I was working for was a company that cared a lot about the end product, and it's sense of polish, both visual and interactive, to the user. For us front-end developers, this meant that we needed to control HTML, CSS, and JavaScript in ways that made using GWT like trying to play the piano with boxing gloves on
First of all , GWT is not dying technology, its usage increases, and its latest version is 2.2. I am using GWT for 2 years, since version 1.6. Its improvements since them is quite amazing.
Since GWT is client side technology, it does have only positive effects of your application scaliblity feature. Because server side web technologies such as jsf, struts, wicket are server resource consumers, but gwt does not need any server resource to render user interface..
But there is problem for your team. Because your team has no java experience, it would be quite difficult to adapt yourself two new technologies java and gwt.. If you have time to learn , I would strongly suggest GWT.
It takes approx 1 year to become proficient in GWT. Using GWT pays off if you develop an application as sophisticated as MicrosoftOffice or PhotoShop. It makes no sense to use GWT for small and relatively simple apps, IMHO. GWT is a time killing framework indeed, and you have to have very strong reasons to use it. I think that 99% of web apps don't need GWT.
GWT is not dying framework, but time killing framework. It has security issue. You can do easily CSRF(Cross site request forgery) request to the GWT applications. Also Java and Javascript are totally different languages, you can't translate easily. For your productivity avoid GWT.
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 11 years ago.
Can someone give me some insight on a scenario like this.
Say a company has en existing Joomla site, not complete but just has all the modules, plug-ins, and components installed that they believe they will need.
If someone new where to come in and given the general idea of what the site needs to do, and by accomplishing this they need to make sure all plug-ins share data between each other update information between each other when ever one module is updated. As well as fixing and modifying the template to take shape and form of how they envision the site to be interacted with.
Would jumping into this project be more trouble than its worth? Would creating something from the ground up using custom developed pages rather than using Joomla as a back-end/front-end be too much of a hassle.
Also given that the existing installation has 301 tables to sot through.
Joomla is more than just a CMS, it is also a pretty solid "Development Framework". Modifying existing software will be faster rather than developing from scratch, especially if it is that big.
Read more about Software Development Process, it will help you with your evaluation. As far as I remember development cost is 2x less $ than maintenance in first 5 years.
Starting from the ground up can be not such a good idea for a large project. Working with another framework will result in "reinventing the wheel" and introduce new problems and will require more time for user acceptance.
I know too little to point you in the right direction... 1st of all Joomla is terrific choice, object oriented, it is extensive and very powerful. MVC architecture is huge plus. Plug-in system is easy and extensive. Modules are easy and customizable.
I suggest using Zend Framework if you want to "reinvent the wheel". ZF is exceptional choice but your cost will be MUCH higher. You will have all similar functionality and features like in Joomla: OO, MVC, singletons, layouts, placeholders, modules (components), plug-ins, etc... Comparing ZF to Joomla's "Development Framework" is like comparing Ferrari to Honda Civic.
Long story short: I would try to stick with Joomla and create my library extending Joomla's classes... this will help automating a lot of things (reduce code, etc...). If I was to give a quote to the client I would try to see what they want/their experiences with existing project (check with their IT department, etc). If experience was horrible from day 1 and it was because of software and not hosting/db/hardware/network/etc then I would give 2 quotes: 1st for recreating in Joomla, 2nd for recreating in Zend... and explain strength/weaknesses of both. If software behaved 'OK', with minor to medium problems/bugs/errors I would reuse existing project.
Hope this helps...
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