I'm new to GWT so this may be a dumb question but I didn't find a good answer to it anywhere.
So, how should I create Place objects in GWT? Should I create them as finals in my ClientFactory and reuse them everywhere?
the Place objects Eclipse generates eat a string token as their parameter what should it be?
My Understanding is the following: I should create final Place objects in my ValueChangeHandler for those pages that are static and reuse them everywhere. Those 'Place's that are relatively dynamic should be created like
new MyCoolPlace("MyCoolPlace" + someRandomNumber)
but isn't it kind of dumb using random numbers each time i need to navigate to a new page? also will the history be cleared of the objects which i created say hours ago?
Currently I have a problem with figuring out how this mechanism works:
I have a form. For, say, adding vegetables to the DB
1. User fills it
2. Submits it
3. Gets to a thank you page
4. Clicks a link in the menu to add a new vegetable
5. Gets to the form but it's already pre-filled with the values user previously entered.
I need the form clean on step 5. But if the user clicks the browser's back button on step 3 I want it to be pre-filled.
Question about final:
I think not. They are lightweight objects and places can have values into them. They are not a limited set of places values (at least if you parametrize them).
Question about form values:
The normal behaviour is when yo go back to -let's say- "vegForm" you obtain the clean view (it's because your URL token is simple vegForm). What happens I think it's you're reusing your view without initializing. Your presenter (or whatever has the UI logic) should obtain the view and call "reset()" "init()" or whatever you want.
If you want to hold your values when you go back you should save them in your place object. It is: field values. And your PlaceTokenizer (the object that transform between URL and Place object) should take care of them. By example: vegForm/potato,green,... (don't remember the standard notation).
The problem is how do you save into the URL the values you entered before clicking Save?
What I'd do is "saving" that state into the URL before saving:
History.newItem("vegForm/potato,green,...", false);
And that will get into the history stack. When I say false it means that the GWT History mechanism should not react to that URL avoiding loading the view again. When your user clicks back she should go back to form(with values). If your user clicks back again the she should go back to form(clean).
By example:
User clicks add veg -> #vegForm
User fills data and pless save
-> #vegForm/value1,value2 (saved in History with false argument)
-> #okPage
User clicks back
-> #vegForm/value1,value2 (form with saved data)
User clicks back
-> #vegForm (form without)
Initialization
Take into account you always must initialize the view.
If you don't have params, to clean it (it can be a reused view)
If you have params, to fill the form with them
Related
I tried the example which is showing how to get data from history to re-generate UI; The thing I see mostly in all "history usage" examples are related to UI re-generation only so it is none-static way...
But what about "each UI state may have its unique url something like JSF does with flows"? For example I have app url like a
http://localhost:8080/myapp/MyApp.html
the app default UI contains main menu which is helping to navigate through my test catalog; I tried to make possible keep the UI dynamics in history by building url in this way
http://localhost:8080/myapp/MyApp.html#menu_testcategory_page1
but when I click internet browser "refresh" button the url keeps the same as http://localhost:8080/myapp/MyApp.html#menu_testcategory_page1 but the UI comes back to its default state :(
So my question is
is there an optimal way in pure gwt to stay in the same UI state even after browser's refresh button is clicked (I mean the unload/load window events occur)?
thanks
P.S. gwt 2.3
You should implement Activities and Places pattern: http://www.gwtproject.org/doc/latest/DevGuideMvpActivitiesAndPlaces.html
I am using it for 3 years, and it works very well.
Note, however, that when you reload a page, you lose all of your state, data, etc. If you need to preserve some of it, you can use a combination of a Place (#page1) and a token that tells the corresponding Activity the state of the View representing this Place, i.e. (#page1:item=5).
You probably just forgot to call
History.fireCurrentHistoryState();
from your entry point.
In my application I am using DefaultDataTable with SortableDataProvider which has LoadableDetachableModel as the model.
I used it to display a set of records ( say RecordList page). When I add or remove some records and load the page RecordList again, it displays the changes. However, if I use the back button of the browser and go the RecordList page which was rentered earlier ( before adding/ removing the records ). The DefaultDataTable still has the old sets of records. This is a big issue when records are deleted.
For example, If I delete a record and press back button then the page fails as the record it is trying to show does not exist in the database. Adding does not create an issue because it simply does not get listed in the set of records.
In another page, I just have PageableListView with LoadableDetachableModel. It works fine with out an issue.
There are one or two things that you can do about this.
First please check whether the data provider has the latest data.
Secondly make sure that the set of records with the Data provider is refreshed when the browser back button is hit. Ensure that the data fed to the Data Provider is refreshed in a method other than constructor. Because constructors will not be called when you hit back. So you would need to use a separate method. Ideally you could use the same method, but called from both constructor and when back button is pressed.
I would like to know what is the best method to have an action return different views. Let's say you have a form for submitting data, but you want to choose the view depending on what data is submitted. I would prefer not using a redirection, since there is stuff I want to be displayed in the data that is posted.
An example of this would be to have an Edit form that displays a Details view when clicking on Save, but without using a redirection.
I know this could be done with a single view containing a conditional if statement to display this or that, but there are cases where I would prefer my views to stay simple without too much code in them. If the controller could just choose the view to display once the data is posted, this would be great.
There is an overload to the View() method that allows you to specify the name of the View you want to return.
return View("DetailsView", model);
You should be using the Post/Redirect/Get pattern. You can still "display stuff." You can pass an ID on the URI and look them up in the new GET or use TempData.
Attempting to circumvent Post/Redirect/Get is not a good solution. Among other things, it breaks the back button.
I am facing a strange issue!!
I have a set of property page with same storage file.
The scenario is as follow..
For the first time opening the properties by right clicking on the project, list of property pages are viewed. I click on the first property page and make changes then apply the changes to the file.
Now I select the second page, it shows the changes that were applied from the first page.
But now without closing the properties i go back to first page and make changes then apply the changes.
Then again I go to second page it wont show the updated data. The changes that were applied are not viewed until I close the properties and reopen then by right clicking on the project.
My question is
"Is there any way to reflect changes on the pages without closing the properties??"
I appreciate your valuable time you will give for reading and replying..
Plz help
Your problem seems to just absent of reliable model which can notify problem.
If the properties are related IProject.
You should use ScopedPreferenceStore as model.
IScopeContenxt scope = new ProjectScope(myProject);
IPreferenceStore store =
new ScopedPreferenceStore(scope, "myProperties(qualifier)");
IPreferenceStore can manipulate primitive data, default value. And it support property change event. You can create multiple instances of IPreferenceStore, If they have same scope and qualifier then automatically synchronized. So individual page can retrive input model without coupling.
I am looking for a good pattern for performing basic property editing via a modal view on the iPhone.
Assume I am putting together an application that works like the Contacts application. The "detail" view controller displays all of the contact's properties in a UITableView. When the UITableView goes into edit mode a disclosure icon is displayed in the cells. Clicking a cell causes a modal "editor" view controller to display a view that allows the user to modify the selected property. This view will often contain only a single text box or picker. The user clicks Cancel/Save and the "editor" view is dismissed and the "detail" view is updated.
In this scenario, which view is responsible for updating the model?
The "editor" view could update the property directly using Key-Value Coding. This appears in the CoreDataBooks example. This makes sense to me on some level because it treats the property as the model for the editor view controller.
However, this is not the pattern suggested by the View Controller Programming Guide. It suggests that the "editor" view controller should define a protocol that the "detail" controller adopts. When the user indicates they are done with the edit, the "detail" view controller is called back with the entered value and it dismisses the "editor" view. Using this approach the "detail" controller updates the model. This approach seems problematic if you are using the same "editor" view for multiple properties since there is only a single call-back method.
Would love to get some feedback on what approach works best.
I don't think any of the Apple examples (or anyone else's) actually show you how to structure an entire real world application. Instead, each example is just a test harness which shows you how to use one particular feature of the API but pays no attention to how that feature really integrates with anything else. Data models are given particularly short shift.
I prefer a design in which the data model is the spine of the application upon which hands all the view-controller/view pairs. The view controllers do not communicate with each other directly but instead communicate through the data model. The data model tracks what information the app is currently working on and therefore what data each particular view controller needs at any given time.
Let's use a contact manager type apps as an example. The basic of the data model would be a list of contact objects each of which in turn would hold attributes of a contact. The data model would completely control access to the data and monitors which data was currently being used. The UI is hierarchal such that the user first sees a list of all contacts in a masterView, then the details of each contact in a contactDetailView and then can edit each contact attribute in a custom attribute edit view for each type of data so there is a nameEditView, a phoneDetailView, an emailEditView etc. Each has a paired view controller masterVC, contactDetailVC, nameEditVC etc.
The to build it's tableview, the masterVC ask the data model for the number of contacts, their divisions into sections and then request each particular contact object at each particular index path so it can display a table. When the user selects a table row, the masterVC tells the data model which contact object was selected by sending it the index. Then the masterVC pushes the contactDetailVC. It does nothing else.
When the contactDetailVC activates, it ask the data model for the currently active Contact object. It doesn't know or care how the current contact was selected nor even which view/VC preceded it. The data model returns the currently active contact. When the user selects a field, the contactDetailVC tells the data model which attribute of the contact was selected and then pushes the proper editorVC onto the stack.
When the editorVC loads it ask for the data model for the current contact and the current attribute being edited. It doesn't know or care how the current contact attribute was selected nor even which view/VC preceded it. When the user makes a change, it ask the data model to save the change (the data model can refuse if verification fails for some reason) and then pops itself.
Internally, I like to implement the data model in two parts each managed by separate object. One is the abstracted data manager itself in this case a Core Data stack. The second is an user defaults manager that tracks the actual state of operations in the data model and saves them to user defaults. A master object holds these objects as attributes and serves as the interface of the data model.
This type of model makes it easy to suspend, resume or restart the application back to its previous state. Since each view/VC is self contained, when you restart the app, you just push all the views on the stack without animation and the last one pushed pops up fully populated with data even though the user chose nothing in the previous views and indeed did not even see them.
It also protects the user from data loss in the event of a crash since each VC saves its data and the app state every time it pushes or pops. It's easy to add additional view/VC because each VC only has to know about and communicate with the data model instead of bunch of other VC. It makes the components of the app easy to use in different versions of the app or in different apps altogether.
Edit:
Do you just hard code some if
statements to pair up the attributes
with the correct editor, or are you
doing something more dynamic based on
the entity/attribute metadata?
In most the most common design, the Contact entity could have a variable number of phone#s, emails or other data fields so each attribute would actually be a separate entity and the Contact would have a relationships pointing to those entities. When the user selected that contact to edit in the ContactDetailView, the data-model would simply mark the NSManagedObject representing the desired attribute of the contact. It could do so by setting an attribute like "lastChosenAttribute" or storing the URI for the object. When the editor view loaded it would be hard coded to ask the data-model for the "lastChosenAttribute" and would receive an NSManagedObject for a phone#, email etc. The editor would make changes to that object and they would be automatically saved back into the contact.
For data that is singular, such as a name or name components, the data-model would provide the editorVC with the contact entity and the editorVC would be hard coded to ask the contact object for that specific attribute.
It's a tough call--the View Controller Guide recommendation seems cleaner conceptually, but the other method can be easier, especially if you're using Core Data. To give a blanket generalized opinion, I would say use your first method if you're using Core Data, since managed objects inherently have their own context and can update themselves (and classes such as NSFetchedResultsController can automatically respond to updates).
If you're not using Core Data, I would go with the "official" recommendation, since it makes it easier to manage updated properties manually. As to the concern about multiple properties, it's certainly possible to have multiple delegate methods and call the appropriate one. For instance:
//if property is an address
if ([self.delegate respondsToSelector:#selector(editorView:didUpdateAddress:)])
[self.delegate editorView:self didUpdateAddress:theAddress];
//if property is a name
if ([self.delegate respondsToSelector:#selector(editorView:didUpdateName:)])
[self.delegate editorView:self didUpdateName:theName];
This could get hard to manage, though--you'd probably want to have an abstract superclass for properties, or something along those lines.