I have a GWTP application which has no entry point because I don't ever need to run this application on its own. Rather I want to use it within a standard GWT application which has an entry point, implements its own history management mechanism, uses its own implementation of MVP framework, has its own dependency injection and so on.
The question is: Is it even possible to nicely integrate a GWTP application within a standard GWT application?
Consider this use-case for example: I want to show a popup dialog when a button is clicked in a view that is implemented in the GWT application. The popup dialog is a GWTP PresenterWidget implemented in the GWTP application. How is it possible for a non GWTP presenter to show a popup and make sure all life cycle events are properly called.
I know it's a broad question but I'm looking to see if any body has ever tried to integrate two such applications together. If not is there any advice on how to approach this problem at all.
Thanks in advance
In that kind of context, I would suggest to build your home made mvp framework. It would be easier and cleaner than using a subset of the capabilities of GWTP.
That being said, it's not imposible, but you will have to use a complete hierarchy of presenter / presenter widgets. But that won't mean that the lifecycle will work... The lifecycle of GWTP is strongly tied to internal Navigation Events and if your application doesn't use this feature of GWTP, you're likely to lose all its advantages.
Here's how you can embed a GWTP application in your own already existing application:
https://github.com/ArcBees/GWTP/wiki/Website-Embedding
We've already worked on migrating an existing application to GWTP by embedding the existing application IN GWTP while gradually migrating the existing code base, but not the other way around.
Related
In the past I have worked a lot with GWT and GXT and I'm rather new at Wicket.
We want to have widgets in an existing Wicket application.
These widgets are completely stand-alone "applications". Would GWT be a good solution to do this?
Also we use a lot of Ajax requests (in the current widgets) to update / retrieve data. Since I found that GWT handles those ajax requests very nicely with RPC mechanism I thought it might be a good idea.
I've used GWT and Wicket in a moderately complicated environment. The integration is pretty smooth as long as you use JavaScript for any of your integration points. Make sure you setOutputMarkupId on components that you need to update from the GWT end of things and you’ll be set.
Whether it’s a good idea or not is completely dependent on your team and project. I used it to integrate an older drag & drop tool into our new wicket based application. It worked well as a stopgap until we redesign the GWT app using wicket + jquery.
First off, I've never used GWT before. I have good experience in HTML/CSS/JS/JSP.
I'm looking for people's opinions on the suitability of Google Web Toolkit for a brand new web app I'm developing.
A big requirement is that the UI is attractive and well designed (Does not look like a clunky Java/Swing App).
It should look like any typical HTML/CSS/JS based modern website.
It is an internal company application so no SEO is required.
JSF is not an option.
The web app frameworks used will be Spring Webflow and Spring MVC. It will use lightweight controllers to communicate with a service layer.
Would Spring Tiles combined with JSP be an easier or more flexible option than GWT for what I am trying to achieve?
Advantages/Disadvantages of GWT and other options welcome.
Thanks
Advantages of GWT
You don't really need to know any JavaScript, since all your client side code will be in Java
This is usually the main reason people go for GWT. They're backend developers who know Java but don't know Javascript, and they don't really want to learn it. Still, you should be careful about this. GWT is a very complete and complex framework with many concepts that are specific to GWT. Even though you'll be coding in Java you will still have to go through many tutorials and documentation before you can build a clean GWT app
Ready to use widgets, like date pickers, dynamic tables, layout panels, popups
It's not really specific to GWT. Other front end framework, like jQuery or Dojo or whatever also give you these. You can have a look at the GWT Showcase to see what GWT has to offer.
GWT takes care of a lot of complex and potentially dangerous stuff for you.
Stuff like Cross-Browser Support, Internationalization, Image and static resources bundling, Front end security, Ajax communication with a server, Events and MVP (just like MVC) framework support. Have a look at the documentation, it is very well done and very thorough.
Debugging is easy
GWT has two different 'modes'. When you're building your app for production, gwt will compile all the java code for the front-end that you wrote into javascript. This javascript will be executed in your clients' browsers. But when you're developping, you can run your app without compiling your java code to javascript. This lets you use a debugger to debug your interface. It's a very good tool.
Disadvantages of GWT
As I said before, GWT is a full framework, with concepts specific to it. Don't think that just because it's in java and you know java that you won't have to learn new stuff.
Interfacing GWT with back end frameworks is not easy
The most common way for your GWT client code to communicate with a server is by using GWT RPC mechanism. It means that you will need to have servlets that implement specific interfaces. You should definetly read the docs on client-server communication to see if that fits well with Spring. A search on SO or Google should give you pointers to setup your application.
I am trying to create an application which will have different views for mobile, desktop and tablet. It is on the lines of MobileWebApp sample from GWT. I am looking at GWT MVP tutorial and have a basic app working.
I was thinking if I should use GWTP and if there would be any advantages of using GWTP instead of GWT MVP(activities and places)
Also, any ideas how different views would bind to the same presenter. There might be differences in what features are available on mobile view and desktop view.
I have done something like this, although at a time before Activities and Places. So back then I've written the MVP framework myself. I placed all the common code, such as Presenters, TransferObjects and Utilities in a separate GWT module. Then each UI became a separate project as well, holding it's View classes and UiBinder stuff, inheriting from the common module. So actually each UI project is a complete GWT application. The GWT applications have to be deployed under different context, thus have different URLs. You then need some smart JavaScript on your welcome page to redirect a visitor depending on there device.
I don't think you can solve this in one GWT app. Or you'd have to come up with a really really clever solution using Deferred Binding (probably it's replacement functionality) and the Linker subsystem.
You can create different views in for a presenter in gwtp. GWTP makes it easier to handle such a scenario. There is an open-source Customer Experience framework which has a sample to create a mobilewebapp using GWTP. You can check it out here- http://code.google.com/p/gwt-cx/
I've been looking into GWT and MVP recently and to be honest I'm very confused. My project will include around 40 different places or views all together. While reading multiple tutorials, some follow Model-View-Presenter and others use Activities and Places, all under the subject of MVP, GWT.
I'm not sure what to follow for a new MVP, GWT 2.2 project.
Many thanks,
Alex
Alex,
Activities and Places are Google's implementation of the MVP framework. There are many well established additional MVP frameworks for GWT which encompass many additional features not yet incorporated into GWT. The two I would recommend are:
GWT Platform: http://code.google.com/p/gwt-platform/
MVP4G: http://code.google.com/p/mvp4g/
They have many additional features to reduce the amount of boilerplate code you have to write to implement solutions. They are worth a peak before choosing Google's A&P.
Cheers
Gene
Activities and Places is the MVP solution that was implemented in GWT 2.2. Before that, MVP was only a recommended approach without an official framework provided by Google. That's why you're getting confused.
I would recommend you to stick with Activities and Places, since it's the official Google solution for MVP.
I hope it helps.
It turns out that an Activity takes the role of a Presenter in the MVP design pattern. Not all of your presenters need to be Activities, but if you have an Activity you can think of it as being a special kind of Presenter with a well-defined lifecycle used for transitions from one "place" to another.
So it's not a choice between MVP and "activities & places". Rather, they're all of the same idea. The new activities & places framework is just a refinement.
Alex,
Activities and Places (as well as ActivityMapper and more) are classes which the GWT team provided to formalize their earlier MVP pattern recommendations. Some time ago I've tried the "raw" MVP recommendations and am currently using the higher-level approach the aforementioned classes provide. It certainly feels easier to use the new classes. In addition to a nice MVP abstraction, you get the important aspect of handling browser history navigation in your application practically for free.
The MVP API is here to stay, it seems, so if you're using GWT 2.2.x I'd also recommend utilizing the new MVP classes from the inception of your project.
Activities and Places are not a MVP framework! Google removes this "disturbance" in later docs. it is just a browser history framework (to easily (de)serialize state of the app). but on implementing MVP and using A&P it turns out that in many cases it is a good idea to merge activity and presenter.
in a more general case one activity could start n presenters.
We used activities and places along with presenters in our design. We also used MVP.
The setup was a view, viewImpl, and inside the view interface, if needed, was a presenter interface that was also declared. The view interface was a pass through to the viewImpl implementation class. The activity went to the viewImpl based on it's business logic and in our case, the viewImpl went to a stand-alone composite widget.
If it was needed, the composite widget used a presenter to get back (another pass through) to the activity. No business logic was in the view or the viewImpl by the way, that was only in the activity. It worked well!
We're planning on creating a feedreader as a windows desktop- and iPad application. As we want to be able to show Websites AND to run (our own) JavaScript in this application, we thought about delivering the application as HTML/CSS/JavaScript, just wrapped by some .NET control or a Cocoa Touch webbrowser component. So the task at hand is to find out which framework to use to create the HTML/CSS/JS files to embed in the application.
For the development of the HTML/CSS/JavaScript we would be happy to use Vaadin, GWT, or some other framework, as we're a lot better with Java than with JS. We favor Vaadin after a short brainstorming, as the UI components are very nice, but I fear that most of the heavy lifting will be on the server and not in the client (and that wouldn't be too nice). We would also like GWT, but the Java-to-JS compiling takes a lot of time and an extra step, and slowed down development time in the past when using it.
The question is: which development framework would you choose (given you wanted to implement this project and you mostly did Java so far) and why? If there are better framework options (List of Rich Client Frameworks), please let me know.
Edit: The application will need to talk to our server from time to time (sync what has been read for example), but mainly should get the xml feeds itself. Therefore I hope that most of the generated code can be embedded in the application and there doesn't need to be heavy activity with our server.
Edit2: We (realistically even if you doubt) expect at least 10000 users.
Based on my experience with Vaadin, I'd go for that, but your requirements are somewhat favoring pure-GWT instead.
Vaadin needs the server and server connection. If building mostly offline desktop application, this can be solved with an embedded Jetty for example. (synchronize with an online service only when needed), but for iPad you would need to connect online right away to start the Vaadin application.
GWT runs completely at the client-side and you can build a JavaScript browser application that only connects when needed.
Because Vaadin is much quicker to develop, you could build a small Vaadin version first and see if that is actually problem on the iPad.
On the other hand, if you can assume going online right away, you can skip the local server installation altogether. Just run the application online and implement the desktop version using operating systems default browser control (i.e. the .NET control you suggested). Then Vaadin is easier.
Vaadin is just framework base on GWT but have two very important features:
don't need to run GWT compiler. It is pure java. Of course if not add addons because then gwt compiler must run.
you don't need to write communication code. So you don't need to solve DTO problems, non-serializable object mappings and dont need to write servlets.
I use Vaadin in my work for one year and we haven't performance problems yet (desktop like application with ~500 users). IMO very good solution is to use Vaadin just for UI, logic move to independent beans and connect this two elements using Spring or Guice.
In this case you should use MVP pattern and Domain Driven Development.
Bussines beans is domain objects and logic that use view interfaces to send responses.
Custom Vaadin components (could extends standard components) implements view interfaces.
That way is good when you decide to change UI engine if Vaadin is not for you. Just rewrite guice/spring mappings and write new implementations of view interfaces.
My 3 cents:
If you decide to use vaadin, You will benefit from already GOOD LOOKING components. Since you dont want to write (alot of) CSS , vaadin is already good looking out of the box. How ever, Vaadin is a SERVERSIDE framework. User interface interactions will hit the back end even if they dont involve getting any data (e.g moving from one tab to the other) .
If you decide to use GWT, you will have to atleast style the application (this is not hard) . There is also the problem of long compilation time (but you can test and debug on hosted mode which allows you to run the application without compiling , then you compile only when deploying). The main advantage of gwt is that you control what gets sent to the wire, For UI interactions that dont require getting data from the backend, it will work purely on the client side. You the developer will determine when to send a request to the back end. (Doing RPC requests in GWT is very easy)
Hope this will help you make the decision.