I am thinking about developing a new application using web toolkit. I decided that the best option is going to be to use the Model-View-Presenter Design Pattern. After doing plenty of research, I found two different ways of implementing the skeleton code. (I am still trying to learn MVP and how to best utilize the disjunction between the model and the view)
Here are the two links discussing GWT MVP
https://developers.google.com/web-toolkit/doc/latest/DevGuideMvpActivitiesAndPlaces
https://developers.google.com/web-toolkit/articles/mvp-architecture
I read through and understand all the information in the second link, how you associate presenters with views, and how you have your custom events and such. I really like this because this means that several developers will be able to work on the project I have in mind.
However, the first link, also points out some interesting stuff, mostly using XML and #UiBinder and other things. I feel that those will not be necessary for this particular application but I want to make sure I have not overlooked anything.
Basically - How good of a programming practice is the style the style in the second link (the one with presenters for each view)
Thank you
You should be not be comparing MVPActivitiesAndPlaces and MVP . If browser history management is not your concern use only MVP.
Activities And Places are not mandatory for MVP. They only allow you clean browser history management which integrates nicely with MVP architecture.
UiBinder is not mandatory for MVP. They can be used with MVP.
The MVP design paradigm mostly is driven with Unit testing as main driver and to keep out slow running GWTTestCase out as much as possible.
At the heart of this pattern is the separation of functionality into
components that logically make sense, but in the case of GWT there is
a clear focus on making the view as simple as possible in order to
minimize our reliance on GWTTestCase and reduce the overall time spent
running tests.
Related
I understand from threads in this forum and the Google GWT forum that in the GWT world you typically load just a single page and then what appears to a user to be a different page is just the same page with it's content being updated by user actions. A lot of posts imply that you develop your app as you would a desktop application. That sounds easy if you have done desktop development but I am coming from a pure Web services/ Servlets/ Struts background and want to see a very basic example that shows the proper way to implement a GWT app where you show a user a txt box and button and when they click the button, the view is replaced with 2 different components.
There are plenty of basic apps I have done and plenty of complex multipage type ones but I just one that takes me past the click a button to see a message type app to the next level.
Any links to such an example would be welcome
I recommend to study Activities & Places design pattern. It is the best approach, in my view, for large applications with multiple views. It provides a lot of important functionality "out of the box", like browser history management, support for tokens, efficient memory management, etc.
You may want to look into the Model-View-Presenter pattern (MVP). Using this pattern correctly will greatly decouple your application, allowing you to create views that are not only highly modular and disposable, but are very easy to swap out and change.
In fact, Google fully recommends the MVP pattern when developing GWT applications. They provide a full example and walkthrough of a MVP GWT application here, which I imagine is based off of a Google I/O presentation given on best GWT application architecture practices back in 2009.
I've been following this pattern with my latest GWT project and it's working out extremely well. It's very easy to add, remove and swap views.
I have worked on the .NET side of things but I am looking at new open-source based web frameworks for a new project.
I looked at LIFT-web, Play, Ruby on Rails etc. LIFT seems very promising for out of the box security and performance. But it claims to have a new approach "view first" instead of MVC. This sounds very similar to the ASP.net web forms paradigm, which was great for drag and drop development but had challenges in terms of testability and having control on what actually
I am wondering whether testing and having full visibility and control on the runtime behavior of LIFT will be difficult. I will appreciate any feedback from people who have used LIFT, better still if they have used both.
Thanks!
I can see why you think they might be similar, but in practice it's not really the case... not for larger applications anyway. If you're building a trivial application in a similar style to web forms, then you'll see similar issues. Lift snippets are in some respects similar to web forms user controls, but the latter are typically abused with munging all manner or content, request, state and so forth together which can indeed make things difficult to test. It's also possible to do that with Lift, as the framework won't stop you. However, idiomatically I wouldn't do that, as I try to ensure my snippets (user controls if you like) are referentially transparent NodeSeq => NodeSeq (xml to xml) functions. Snippets have an exceedingly close relationship with rendering content, and thats all. In addition, you may be interested to look more closely at the site map feature (many people overlook it), as there are some interesting ways in which that can be employed as a mini-controller w/r/t to the incoming request.
So, to try and qualify somewhat, you could indeed make ugly, untestable code with Lift - many people do - but if you keep your business logic properly separated out from the web tier and employ some developer discipline it's a manageable issue. In the main, the benefits largely outweigh the cons - especially in light of no other Scala web frameworks implementing the kinds of security or comet features Lift has.
The bottom line is that if you're building a CRUD application, then its highly likely Lift isn't for you. However, if you're building a rich, ajax or comet app, then its certainly going to be worth a look.
Hope that helps.
PS: You might be interested in checking out "Lift in Action"; it covers some of these topics - http://www.manning.com/perrett/
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.
I have to create now a multi-screen Silverlight 4 RIA application with MVVM.
Each of these screens has to be devided in multiple regions (for example master-detail scenario whereas each of them is a different section and one has control on the other).
Can you give me some ideas what should be the right way to implement such an application?
Is Prism the right choice? I started reading the Prism manual and liked very much the idea of having regions and screens switched and controls in a very flexible manner, but, as said above, I find it too overkill to split it all over many assemblies.
If Prism IS the right choice, then I would appreciate any kind of guidance or reference to guidance on this particular scenario (multiple screens & regions and OTOH not getting my solution spotted with a gazillion projects.
I believe that PRISM is the correct choice for building an application with multiple regions and views. You could argue that that is almost the definition of a composite application.
But I would also remember that you don't have to use all the components PRISM has, you can pick and choose. I would recommend that you consider each aspect of PRISM and test/prototype to ensure you are happy with the facilties offered. In a large application I have built I use PRISM but after some prototype investigations I only used EventAggregator and the Modularity capabilities.
I chose not to use the region support as I found working with ItemControl and ContentControl components in Silverlight gave me the ability to inject views and partial views into my interface.
I found experience from ASP.NET MVC proved useful in considering how to coordinate/break up my UI into partial views.
Hope that helps. The Stocktrader application is a great example to learn from (included with the PRISM distributable).
A question for all the GWT gurus out there.
I'm a newbie in GWT and am trying to understand the best practices of coding a GWT application. I have gone through "Large scale application development and MVP" based on Ray Ryan's talk at Google I/O 2009 and it has given me a good starting point. I downloaded the sample source code as well for the Contacts application based on the best practices listed.
The application I'm trying to develop using GWT is a bit bigger (in terms of the modules involved) when compared to the sample "Contacts" application & so I want to split it up into multiple functions.
I have been reading that having a single Entry point in a GWT application is a good idea, and I don't want to dump all the code in one single AppController class & one single RpcService, what would be the best approach in this situation?
How would I go about dispatching the control to multiple controllers? Is there a way to achieve this using some classes in the GWT framework?
For large GWT apps, a framework like GWTP (which is a fork of gwt-presenter and gwt-dispatch) is almost necessary. It provides things like Places for handling location/history, a handy Presenter framework, EventBus, and really simple codesplitting.
If you are developing very big application then split your application into multiple modules.
For client side MVC pattern I suggest PureMVC.
http://puremvc.org/
If you're worried about initial load size and it's possible to load your big app in different chunks, consider Code Splitting