i am working on a medium sized gwt app it uses MVP and activities/places, gin/guice. in the last month i am more and more disgusted by the many boiler plate classes/ much boiler plate code - writing a place that simply (de)serializes some parameters is a pain. Setting up activity mapper and managers is also only a matter of correct copying and pasting.
now i again stumbled across gwtp and read some wiki pages. I think with it i could delete many classes on client side.
but is it a good idea to migrate a project to gwtp at this state? does anybody has experience with such an migration? could activities/places/boiler plate coexist with gwtp stuff?
Depending on the size of your app, it may require a lot of work. If you're not used to GWTP, I don't suggest to do that yourself until you're used to do it.
I've personnally done it on several projects, small, medium to large size and it can be done, but it needs that you understand the workflow perfectly.
It can also live together with some existing code, we did that on a large scale project that had a lot of legacy code.
But I'm afraid that if you're not already a experienced user of GWTP, this will be a hard change to make by yourself.
Related
I am about to start a project that I hope will some day require the capacity for scaling. The key question for me is: should I invest the effort to design for this eventuality now, or should I cross that bridge when I get there?
I know how these things go: everyone thinks their project might scale, but most projects never do.
Is there a set of best practices that will allow you to scale more easily at a later stage, while not investing too much in something that may never be needed?
Obviously I have no experience with scalable web sites. Currently I am leaning towards Scala / Play! / Akka. From what I can glean from the Akka website, it is very suitable for this kind of project (in that it provides a toolset that allows development on a single machine and scaling out to an arbitrary number of machines).
The project is a consumer-facing web site that involves some user interaction (comments, messages, voting etc.). The main focus is editorial, though. It's no Facebook :)
Not being experienced in any of these technologies (my experience mainly coming from PHP, AS3, Objective-C), I probably have a little too much on my plate right now. But then I am not going to go at it right away. I am aware that I need to get some experience using Scala and Play! first.
Any advice is greatly appreciated.
Start out by simply designing you model, build unit tests for that and then set your presentation layer on top of it. As long as your model is sensible, it will be easy to scale Play out to any number of machines. If you go for the build in JPA support, you can always deal with the question of which DB to go for.
You have larger things on your plate for the time being. So just make sure your design is consistent and sensible, then scaling will not be a problem.
You've got a head start by using a stateless web framework like Play! that won't get in the way when you need to scale. As ExxKA says, keep your model clean and sensible. This will help you keep the advantage of complexity.
Don't consider it a failure when you need to refactor your code - or even rewrite important parts of it. This is a natural part of a growing project, like a snake shedding its skin.
There are inevitably things that you'll learn in the process of writing the project, so don't try to anticipate them all right now.
I am looking to build a GWT based web application. Being new to GWT, am looking for suites that provide the best GWT widgets (in terms of user experience, variety, styles, etc.), to help build a web app.
I have come across SmartGWT, but looking for other options/suggestions.
Thanks in advance!
I've done apps in both GWT and SmartGWT. My observations, for what it's worth:
SmartGWT has all sorts of cool features, out of the box. It's easy to be seduced by the SmartGWT showcase.
GWT is converging on SmartGWT, and quickly. For instance, the new DataGrid
can stand up against the SmartGWT ListGrid and come away looking good.
In order for GWT to look good though, there has to be real skill in the
developer. SmartGWT can make anyone look good, it seems, but to make
GWT shine takes skill.
Once you have that level of skill, though, there's no looking back.
GWT seems to me to be much more flexible, a consequence of the building-block approach. SmartGWT is more monolithic.
SmartGWT's design has some portability issues. I successfully took a pure GWT app I made and re-worked it (minimal effort) to run nicely in a BlackBerry PlayBook browser. I took a
SmartGWT app I had made at about the same time, and half the widgets
didn't work.
For an enterprise level solution I'm working on, I'm using pure GWT and I don't regret having made that choice.
I would suggest using standard gwt widgets. Simply because,
1)they are best documented,
2)they are highly customizable via css
3)from what I observe they provide the best performance
4)you dont need to learn a whole new framework built on top of another framework
but if you insist on using a framework then I suggest you take a look at this question
My advice to you is to consider your needs. Plain GWT and SmartGWT both are the best supported, so you need not look for more (unless of course both fail in what you want).
Go to their respective showcases and see what they offer and how it fits your requirements.
If gwt satisfies all your UI requirements, my advice is to choose it over SmartGWT. gwt beats SmartGWT in learning curve and documentation anytime. Also its faster(my opinion). If gwt doesn't satisfy your needs and SmartGWT does, then you should consider making the switch.
I have a year experience in smartGWT, when we started our first gwt lessons, they said use the basic gwt features and build own framework otherwise we can encounter errors which may lead to dead-ends. We considered the idea, but for the project (since we already had deadline) decided to look after some extension of gwt. We found smartGWT. The showcase was really convincing. Remember these are widgets, the basic logic of your system is still up to you.
In case if you start using smartGWT: If you don't use JSON but some normal list of java structures prepare to get hard hours/days to get use to datasources, grids, and few other components. Seriously, it had ridiculous problems (for example switching two configuration code line without reason makes work the listgrid), BUT before you drop the entire idea to use it, after a while it starts to work, and it becomes really impressive and comfortable. This is a kind of work "make it once, will work hundreds of times".
In my opinion:
don't start use smartGWT if you want to make a system which is not too complicated.
start use it if you need complicated system with lot of different features, if you don't have the time to develop everything for yourself: many components are ready in smartGWT.
What's the benefits if I am using Ext-GWT? Compare to GWT, What kind of benefits EXT-GWT could bring?
If you want your application to look like all the other Sencha applications, then go for it. Sencha comes with a set of tools and widgets that might help you make a faster start, but at the end of the day, you will need a deeper understanding anyhow, and climb that hill.
My 2 cents : go for GWT pur et dur.
for maximum flexibility
for better results
but probably a steeper start.
From the sencha site:
Sencha Ext GWT takes GWT to the next level, giving you high-performance widgets, feature-rich templates and layouts, advanced charting, data loaders and stores, and accessibility, and much more.
I was using the widgets in a project which is nice if you need something fancy not in GWT-only.
As someone who has used both extensively, I can attest to the amount of features added by GXT... ...but, at a price. Its deferred layout system is efficient, but it's a steep and sometimes frustrating learning curve, especially if you want to support IE<8.
Note that I haven't used GXT 3.0, but used 2.X for a large and successful enterprise application. If you do not write some kind of web-based unit tests (selenium recommended), you will eventually get to a point where you spend more time fixing layout bug regressions than you do creating new code.
GXT can kickstart your initial development because you can produce feature rich widget very quickly (Grid is especially nice), but when it comes time to start extending and augmenting the default widgets, you're going to hit brick walls with very little documentation.
Another big gotcha... GXT models internally serialize using a Map<String, Object>, which means that any types not explicitly serialized elsewhere in your RPC will give you errors when put in a GXT model. The workaround there is to put a private, unused field of the type you want serialized (enums were my biggest pain). Finally, gxt models are NOT default java serializable, so if you want to store them in sessions or pass them around on the server, it's not going to go well for you.
All that said, once you get the hang of GXT, and provided you don't dig too deeply into its guts, it is a great tool. The widget sets themselves are very nice...
Basically, if you intend to create a monolithic, feature rich, complex app where you need lots of control over how things are rendered, GXT will probably get in your way.
If you want to bang out a shiny app over the weekend, don't reinvent the wheel, and just use whatever works.
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.
At what level of complexity is it mandatory to switch to an existing framework for web development?
What measurement of complexity is practical for web development? Code length? Feature list? Database Size?
If you work on several different sites then by using a common framework across all of them you can spend time working on the code rather than trying to remember what is located where and why.
I'd always use a framework of some sort, even if it's your own, as the uniformity will help you structure your project. Unless it's a one page static HTML project.
There is no mandatory limit however.
I don't think there is a level of complexity that necessitates a framework. For me whenever I am writing a dynamic site I immediately consider a framework, and if it will save me time, I use it(it almost always does, and I almost always do).
Consider that the question may be faulty. Many of the most complex websites don't use any popular, preexisting, framework. Google has their own web server and their own custom way of doing things, as does Amazon, and probably lots of other sites.
If a framework makes your task easier, or provides added value, go for it. However, when you get that framework you are tied to a new dependancy. I'm starting to essentially recreate a Joel on Software post, so I will redirect you here for more on adding unneeded dependencies to your code:
http://www.joelonsoftware.com/articles/fog0000000007.html
All factors matter. You should measure how much time you can save using 3rd party framework and compare it to the risks of using other's code
Never "mandatory." Some problems are not well solved by any framework. It would be suggestible to switch to a framework when most of the code you are implementing has already be implemented by the framework in question in a way that suits your particular application. This saves you time, energy, and will most likely be more stable than the fresh code you would have written.
This is really two questions, you realize. :-) The answer to the first one is that it's never mandatory, but honestly, parsing HTML request parameters directly is pretty horrible right from the start. I don't want to do it even once, so I tend to go toward a framework relatively early on.
As far as what measurement is practical, well, what are you worried about? All of the descriptions that you list have value. Database size matters primarily for scaling, in my opinion (you can write a very simple app if you have a very simple schema, even if there are hundreds of thousands of rows in the database). The feature list will probably determine the number and complexity of UI pages, which will in turn help to dictate the code length.
There are frameworks that are there for getting moving very quickly with a simple blog, django or RoR all the way to enterprise full-stack applications Zope. Not to be tied to just the buzz world, you also have ASP.Net and J2EE, etc.
All frameworks and libraries are tools at your disposal. Determine which ones will make your life easier for your given project and use them.
I would say the reverse is true. At some point, your project gets so expansive, that you actually get slowed down by the shortcomings of the framework. For sufficiently large projects you may, in fact, be better off developing your own framework, to meet your own needs. I have seen many times where people were held back in the decisions they could make, or the work they could produce, because they were trying to do something that the framework didn't anticipate. And doing these things that the framework doesn't anticipate can be very troublesome. The nice thing about making your own framework, is that it can evolve with your project, to be a help to you system, instead of a hindrance.
So, to conclude, small projects should be use existing frameworks. Large projects should contain their own framework.