I have great experience in programming by using java and other languages.
I need anyone who has great experience in using GWT with MVP to explain how to build GWT Application using MVP:
View package : explain what should be in view class.
Client Package: explain what java files are supposed to be here and what is the benefit from each file.
Server Package: I think here all services files( RPC ).
Activity Package: Explain what is the benefit from the classes here , I think here we we connect events with controls in view classes( Am I correct?).
Place Package: I need to understand this very well.
Also what is the benefit from Clientfactory java file?
what is eventbus?
what is placecontroller?
please if you can order which file should be coded one after another?
Thank you in advance,
1) View is a widget with link to its presenter. It should notify presenter about ui events which should be processed.
2) Views, presenters, client(not shared with the server side) model, places, activities, PlaceHistoryMapper, ActivityMapper. About benefits see below.
Are you understand presenters well? According to your question i assume you confuse it with activities.
1.1 ) Presenter creates and manages view, makes rpc and most of 'logic' stuff.
3) You are right, server package is just a java server logic.
4) Activities link places and presenters. I will return to describing activities below.
5) Place has name, token and own Tokenizer which transforms its place to a token and other way round.
6) I didn't use ClientFactory. I prefer dependency injection with google-gin(gwt client version of guice)
7) Event bus is... I couldn't describe better than official javadoc does :)
Dispatches Events to interested parties. Eases decoupling by allowing objects to interact without having direct dependencies upon one another, and without requiring event sources to deal with maintaining handler lists. There will typically be one EventBus per application, broadcasting events that may be of general interest.
8) PlaceController knows where you are(in application :) and may change current place. (obviously, it has getWhere() and goTo(Place) methods)
9) Firstly you need to code application's singletones like PlaceHostoryMapper and ActivityMapper.
PlaceHostoryMapper provides history and converting tokens to places by segregating all PlaceTokenizers.
ACtivityMapper segregates all places and activities and provides second ones by first ones.
Views and presenters are based on interfaces. Next I would declare such interfaces.
Then write places. Then you able to code activities because you have places and interfaces of presenters.
Then in any order implement views and presenters, map activities to places in ActivityMapper and register PlaceTokenizers in PlaceHistoryMapper.
I assume now you have more questions, feel free to ask in comments or by contacts in my profile :)
Related
I know the question is about solving the problem probably by different approach but let me specify in details what I want to ask and how much I understand about it.
We have two mvc approach used in ATG(or many other framework) pull based and push based.
As I understand it formhandlers and droplet both are playing the part of controller in different need, repositories are our model and jsps are providing views..
And if i am right till this point then what purpose the servlet chain is solving?How it fits into this picture of MVC?
Please If possible explain with the help of flow diagram from request to response (end to end).
Thanks a lot in advance to experts.
Please help.I could not find this kind of explanation anywhere.
The first thing to remember with ATG is that it is an old platform. So when trying to understand the different mechanisms through an MVC lens, remember that nothing was designed with MVC in mind-the platform predates widespread knowledge and acceptance of the MVC pattern in web development.
Droplets are a generalized mechanism for invoking Java code from a JSP (and previously, JHTML) template. The closest analogue in J2EE-land would be tag libraries. So you can use them to accomplish many different tasks. You can also use them as a poor man's MVC controller. This is done by coding a custom droplet class dedicated to handling the business logic of your page, and setting relevant page state as request parameters. Then you invoke the droplet as the first step in your JSP page. This is not very different from J2EE model 2 with the odd quirk that first your compiled JSP begins executing, then invokes your "controller" code and then resumes with processing the "view."
Form handlers, as the name indicates, are designed for processing form submissions. These are executed by a link in the servlet pipeline (DAFDropletEventServlet), before the page which was posted to begins rendering. Typical usage with form handlers is that they will send a redirect after executing, and cancel rendering of the page, which will abort any further processing by the servlet pipeline. Form handlers are the closest thing to a "controller" ATG provides. But they are awful for handling GET requests and result in some very unfortunate URLs when used for this purpose.
Why did they create two different mechanisms? Why have they not subsequently introduced an updated MVC model as part of the platform? These questions I cannot answer.
ATG, at the page rendering level, is not MVC. Don't look at it as MVC. ATG, at its core, is an extension of the basic Servlets API.
Forms and form-processing, with the successUrl and errorUrl is kind-of MVC. Droplets certainly are not.
It is perfectly acceptable in an ATG application to be fetching data as the page is rendering (i.e. Droplets)
I'm about to develop this small website, its basically a simple web app to store informations about patients for a doctor.
The company i have got the assignment from demands an introducton with a class diagram, honstly, i have done this already but only for standalone apps, i'm very new in designing class diagrams for websites.
What i'm using is the Ivar Jacobson's iterative metho with usecases, where a usecase includes:
Actors, scenario (representing user-system interactions when all goes fine), and worse case scenatio (solutions when something goes wrong).
By applying this i came to a good conclusion, a well prepared class diagram.
My problem is that i'm doubting whether or not i should include jsp views and servlets(in my case action beans since i use Stripes) in the diagram, i mean, the bridge between the business-classes and the user are the jsp-views and the provided info are going to be processed by the servlets (or action beans), would you include them in the class diagram?
For a small project tis might be not that relevant but what if you have a project with 30 views and 20 servlets, the diagram would become messy and huge.
Do you have some tips about it?
Thank you
If the only reason you need the class diagram is to satisfy the client, best find out what they're looking for first.
If however they're not specific (and ignoring the cynical options) I'd suggest the following:
Create a "Domain Model" diagram. i.e. capture the concepts in the domain and their inter-relationships. So Doctor, Patients and associated stuff.
Don't create a "design" class diagram - i.e. no jsps, servlets, etc. If necessary create a simple architecture picture instead showing how the application is layered.
Rationale: a domain model is good for checking scope and verifying domain rules (relationships). A "design" class diagram only obfuscates that. A proliferation of jsps, controllers, etc. hides the underlying architecture pattern while distracting from the useful stuff in the domain model.
hth.
I have read a lot of gwt-mvp questions that are asked here, but since i'm totally new to this design pattern I would like to ask some questions:
[1] The Activity-Place pattern is a different pattern than mvp?
[2] In the MVP pattern presenters contain the logic. Now the logic of the widgets/controls is defined in the Activities?
[3] The CustomPlace classes are fixed (as the Eclipse plugin constructs them) or can i put data/methods and what kind?
[4] What is the use of the Presenter interface inside a CustomView? What data/methods would make sense to add into it?
[5] I want to build an application that will use many data structures that will be saved into a database. I have read some other posts here and I will make the Model part of MVP live inside each Activity. So i think to create each time the data structures of each activity at start and load its values (if necessary from db) and will update the database after the user goes to another view. What do you think about this approach?
Let's start by debunking one myth: Activities/Places have nothing to do with MVP. Places is about navigation, Activities are about "componentizing" the UI wrt Places. On the other hand, MVP is a design pattern, it's about how to organize your code.
Many people are using their activities as their MVP-presenters, but it's not enforced. The GWT team is trying a new approach where the activity is distinct from the presenter (work underway in the mobilewebapp sample if you want to follow what's going on there). You could also have your activity being your view and making use of an "internal" presenter (similar to how Cell widgets work)
A Place is more or less a URL. You can put whatever you want in it. I'd suggest making places immutable though: build a Place, goTo it, make use of its properties to build your UI.
That's about MVP then. This is only needed to decouple your view and presenter, mostly to make mocking in unit tests easier (this is particularly of the view interface though, not much for the presenter one, unless writing a test harness for you views). In some cases, you might also want to use the same view with distinct presenters; they'll all implement the same interface so the view can talk back to them.
How about the closing of the window/tab? I'd rather use a periodic auto-save, or an explicit save button; and implement mayStop so it prompts the user when there are unsaved changes (similar to how most desktop office apps work —e.g. MS Word or LibreOffice—, and GMail if you try to navigate away before your mail draft is auto-saved)
The Activity-Place is an implementation of the pattern. Google introduced gwt-mvp pattern at Google IO, but only provided it's implementation as part of GWT about a year later.
Yes Activities contain business logic. No, widgets/controls usually do not contain any logic, they just fire events based on user action. The logic that acts upon those events is written by user and resides elsewhere.
I don't use Eclipse, so wouldn't know about Places generated by it. Normally custom Places can contain custom fields and methods. For example they can contain custom place token arguments, i.e. if place token is "#place:id1", than your custom Place could contain field holding this argument.
When View needs to call/access Activity, it does so via Presenter, which Activity implements. For example when user enters all data in a for and presses submit, then you could have a method in Presenter named submit(formData).
Preparing/loading data in activity.start(..) is a normal way of doing things. If particular activity is used a lot, then you might consider caching the data if appropriate.
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!
I need a tutorial for the new GWT MVP framework which is presented here.
The description Google gives is a little bit short for me. What are the meanings of — and how do I use — the following?
Activities
Places
Eventbus
ClientFactory
PlaceHistoryMapper
ActivityMapper
Also, where are the models in this new framework?
Places
These are classes that encode information about where your program has navigated. You might make a Place that means, "I'm on the home screen," and another one that means "I'm editing the user with id 52384. I think a better name for these would be PlaceTags, because they are not actually a place themselves - they just indicate where your program is. The URL is hooked to Places in a PlaceHistoryMapper, in which you can say, "hey, #home should generate a HomeScreenPlace and #edituser:52384 should generate a EditUserPlace (maybe constructed with a field you set to 52384).
Activities
These start and stop your code. Each Activity has a start method that is called when appropriate. You determine what "when appropriate" means by making an ActivityMapper, which has a function called getActivity. getActivity accepts a Place, and you have to decide which Activity to return. If the Place is whatever you've coded to mean "I'm on the home screen," you might return a HomeScreenActivity, and if the Place means "I'm editing the client with id 523584," you might return a EditClientActivity. You can add methods or a constructor to an activity to pass in an id like 523584.
EventBus
This is an object the different parts of your program use to communicate. If you don't want to, you don't need to know very much about it - you can just plug it in where indicated in Google's documentation (that you linked to)
ClientFactory
This is a centralized object whose only responsibility is making other objects. You can also skip this concept if you want to simplify things - you'll just be missing out on the central organization of your objects. The advantage is that if you want to switch them out later for, say, a mobile version, or a mocked-up-for-testing version, you can do so all at once within a single place and the rest of your program doesn't have to change at all. You can also reuse the same objects easily when coordinating from a central place, so you don't have to re-create the whole main screen every time someone goes to #home.
Your Actual Program
All this stuff is just for navigation. Your models, views, and presenters are all set up in each Activitys start() method, which the framework calls when your app should navigate to a new place. In the start method you should start up your presenter (usually using a new instance) and start up your display (usually reusing an instance - the client factory is good for this). When you've created your display, you let the framework know by setting it as the widget for the AcceptsOneWidget that the framework passed into your start method.
This is incomplete, but a good supplement to the docs you mentioned: http://code.google.com/intl/de-DE/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlaces.html
I would also recommend you to carefully listen to the Google I/O presentations, they are a golden key to understand the GWT philosophy:
http://www.google.com/events/io/2010/
http://www.google.com/events/io/2009/
Specially these ones (try to keep a more holistic view of the MVP framework). They do not talk about the real GWT implementation but they give you basic knowledge of MVP. I still am an 8 months noob, so from noob to noob :)
Ray Ryan's overview of the MVP paradigm. Great resource (it was an enlightening for me).
http://www.google.com/events/io/2009/sessions/GoogleWebToolkitBestPractices.html
http://www.google.com/events/io/2010/sessions/architecting-production-gwt.html
Daniel Danilatos's testing for GWT. Here you will understand why all the fuzz for MVP!
http://www.google.com/events/io/2010/sessions/gwt-continuous-build-testing.html