I'm still learning GWT, yet already have to face some kind of challenge for a work I have to do. Can't show any specific code so I'll try to explain it well.
Here's the situation: A certain class "Navigator" creates and save the Presenter instances of my architecture to allow reusing them. There is a method show() inside that same class that actually displays the view related but that system only works full screen by calling RootPanel.get().
What i'd like to do is showing that presenter instance's view inside of a flex panel element declared in a class myView (related to a class myPresenter) that basically uses Flex Panel to structure it's content.
To make it maybe more clear:
class myView{
...
flexPanel.setWidget(firstWIdget)
flexPanel.setWidget(secondWidget) //secondWidget to be replaced by a "thirdWidget"
...
}
I'd like the secondWidget to be replaced by another one, let's call it thirdWidget, that consists of a specific presenter instance's view.
To resume, I'd like my presenter instance's view to not go full screen but only occupy a certain area of the screen.
The displaying is managed almost entirely programmatically, means very limited use of css files and no use at all of xml ui files.
How can I manage this ?
Thanks
Use a SimplePanel as a container for your views returned by your Navigation class instead of adding them directly to root panel, and use that instance of SimplePanel where ever you want.
My EmberJS app is confusing me a lot at the moment. I have a collection view, that in turn defines an itemViewClass of a custom view I have defined in my code. Something like:
App.CarouselView = Ember.CollectionView.extend({
itemViewClass: App.SlideView.extend(),
});
And this CarouselView is rendered inside a template that has a dynamic segment backing it (I hope this makes sense?) . The controller for these dynamic segment is an array controller because the model for these dynamic segments is a collection :) (more confusion, please let me know)
App.SlidesController = Ember.ArrayController.extend();
By now all of you have figured that I am basically rendering a bunch of slides inside of a carousel. And these are dynamically backed in the collectionView by setting the property
contentBinding:'controller' // property set in CarouselView, controller corresponds to SlidesController
The confusion begins now. I want to add a slide to the existing set of slides. So I provide a button with an action : 'add' target='view'
In the SlidesView,
actions:{
add: function(){
var carouselView = this.get('childViews')[0];
// SlidesView has carouselView and another view as it's child, hence this.get('childViews')[0] is carouselView
var newCard = carouselView.createChildView(App.SlideView.extend());
carouselView.get('childViews').pushObject(newCard);
}
}
The above piece of code sucks and hurts me bad. I want to basically add a new SlideView to my CarouselView collection programmatically upon a button trigger. But apparently Ember recommends that childViews should not be manipulated directly and I ought to instead change the underlying content.
It states in my console.log that manipulating childViews is deprecated etc.
So essentially I need to add something to my content to my SlidesController content ? However, I don't want to add something to the content, this is just a soft add, that is providing the user with a slide so that he may choose to edit or add something if he wants to. He can always discard it. A hard add that will require me to persist the new slide to the DB will come once the user decides to save this information.
I thought that if you registered a view with the IoC container as "Singleton" then the same instance would be reused each time you navigate to it, while registering the view as "Transient" would create a new instance each time you navigate to it. Unless I'm doing something wrong, I've found that the IoC "lifestyle" makes no difference, and it's the IRegionMemberLifetime.KeepAlive property that dictates whether the view is re-used or recreated each time. Is this correct? (I'm using Castle Windsor IoC).
When Prism documentation talks about a view being "deactivated", is this simply the process of hiding the view when it is navigated from? And if KeepAlive=False, does the view get disposed at this point?
What about nested views/regions? If a view contains a region with another view inside of it, and I navigate away from the parent view, do both views get deactivated/destroyed (depending on the value of KeepAlive)? What about ClearChildViewsRegionBehavior - where does this fit into things?
I don't know if this apply to your situation but I implement the interface INavigationAware.
If a view should be reused for every navigation I always return true from the IsNavigationTarget method.
public bool IsNavigationTarget(NavigationContext navigationContext)
{
return true;
}
I'm trying to learn the MVC pattern, but each place say something different. So now I don't know whats the true MVC.
So I'm guessing its the most pure MVC:
Model is just data and notify data changes.
View reads the messages of the Model to update the view.
Controller reads the user input from View and changes the Model according.
Implementing
Model knows no one.
View knows the Model.
Controller knows both View and Model.
Pseudocode:
/* Model */
class Color{
color = blue;
setColor(color);
notifyUpdate();
}
/* View */
class ColorPicker(model){
model.register(update);
update(){
this.colorToExhibit = model.color;
}
}
/* Controller */
class Colorize(view, model){
view.register(update);
update(color){
model.setColor(color);
}
}
Some questions:
Is that right?
I can't see why the View cannot change the Model directly, but through Controller.
Suppose I have animations to be performed after an action. Who must handle this animation: the Model, the View, or the Controller? Also: the animation logic is part of the Model, View, or Controller? More: Suppose a Poker game. After the user choose an action (say, 'Raise'), the system must play an animation (say, the chips going from player spot to the desk). How can I see this poker example (with animation) as a MVC? Can you explain and give a pseudocode about that?
Thank you.
Model is just data and notify data changes.
View reads the messages of the Model to update the view.
Controller reads the user input from View and changes the Model according.
The Model is more than just data. The model is also the business logic. It contains all of the intelligence of the system, or at least an abstraction of behind-the-scenes intelligence (such as database calls or other service calls). Consider the saying, "Keep your models heavy and your controllers light."
Model knows no one.
View knows the Model.
Controller knows both View and Model.
The Model knows no one, that it correct. The Model should be portable between applications and shouldn't depend on UI concerns in any way. (The View and the Controller are UI concerns in this case.)
The View knows the Model, also correct. The View basically "binds" to the Model. It presents all of the UI elements and places Model data within the UI elements accordingly.
The Controller kind of "knows the View." It knows which View to which it should direct control, but it doesn't know anything about that View. Nor does it know which View from which control previously came. The Controller responds to events. An event comes in from the UI, carrying some kind of state information with it (a ViewModel, perhaps), directs logical control through the Models (where the business logic happens), and responds with a Model (or a ViewModel, if the shape of the data specific to a particular View is different than the Models) and a View.
I can't see why the View cannot change the Model directly, but through Controller.
The View can manipulate the Model within the context of the user interaction, but shouldn't expect those changes to persist in any way. The View should be considered "client-side" and doesn't know anything "server-side." (Even if you're talking about a native application and not a web application.) Persisting any change is considered a UI "action" or "event" and would go to a Controller to make it happen.
Suppose I have animations to be performed after an action. Who must handle this animation: the Model, the View, or the Controller? Also: the animation logic is part of the Model, View, or Controller?
An animation sounds like an entirely UI-based operation. It would be within the View. Is there more happening than just a UI animation? Does the animation change anything in the back-end? For example, if I have a web application and, when a page loads, I want to fade-in some data (an animation)... that's entirely in the View. The data would be delivered to the View like any other data, and the animation takes place entirely within the UI (View). It doesn't do anything from the perspective of the Model or the Controller.
Suppose a Poker game. After the user choose an action (say, 'Raise'), the system must play an animation (say, the chips going from player spot to the desk). How can I see this poker example (with animation) as a MVC? Can you explain and give a pseudocode about that?
The action ("Raise") is a Controller event. The UI would contact the controller to perform the "raise". So the Controller might have a method like this:
View Raise(GameState state)
{
// Interact with the Models to update the known state of the game.
// The Models would perform the actual Poker game logic.
// Respond with a View bound to updated Models.
}
Once the Controller responds to the UI with a new View, that View would contain any animations to display to the user. (After all, you don't want to perform the animation unless the action was successful, right? When the Controller responds to the UI with a new View indicating a successful action, then the animation would play. It may instead respond to the UI with a View indicating an error, in which case that View would show something else.)
I'll go with the simple Bank analogy.
Tellers are Views.
Runners are Controllers.
Bankers are Models.
The Bankers are the smart ones, they know all of the business logic and do all of the complex calculations.
The Runners are used to transport the money (data) from the Bankers to the Tellers.
The Teller presents the money to the Customer.
A simple representation:
Model
public class BankAccount
{
public int ID;
public int Balance;
public BankAccount(int id)
{
ID = id;
Balance = DetermineAmount();
}
public int DetermineAmount()
{
// Gather transaction info, debits, credits and return a
// sum of the amount left in the account depending on the
// id provided.
}
}
Controller
public class BankAccountController
{
public ViewResult Index(int id)
{
BankAccount account = new BankAccount(id);
return View(account);
}
}
View
<ul id="account-info">
<li>Account ID: `#Model.ID`</li>
<li>Balance: `#Model.Balance`</li>
</ul>
If you are interested in the historical true MVC, then start with Trygve Reenskaug. He created (observed?, catalogued??) it in the late 1970s. For a start, read "Models-Views-Controllers" from 1979. It defines the terminology. Take careful note of it's title - all three roles are pluralized. This is the first thing that most people seem to get wrong.
The best description I've found of the original use of MVC is actually in a presentation dated 2004 entitled "Inside Smalltalk MVC". I would guess that the canonical papers that describe the Smalltalk 80 final version of MVC are Krasner & Pope's "A Cookbook for Using the Model-View-Controller User Interface Paradigm in the Smalltalk-80" and
Steve Burbeck's "Applications Programming in Smalltalk-80: How to use Model-View-Controller (MVC)". Both papers are well worth the read.
If you have some time to kill and don't mind listening to Robert Martin, he did a good keynote at Ruby Midwest 2011 that touched on MVC. It is a little over an hour, but quite entertaining and enlightening. I tend to follow with his opinion that most implementations get MVC wrong. I spent a little time looking around and finally found a diagram that I can link to which describes MVC. The one that I like came from Pope and Krasner.
(source: as3dp.com)
From my point of view, the following are the key points:
a model instance is responsible for notifying the interested objects of changes. Note that these can be any object instances. The diagram shows both views and controllers receiving updates here.
views are responsible for querying the current state and displaying the results. They usually perform filtering or data transformation as well.
controllers are responsible for accepting user input and forwarding view messages along to the view.
View messages are a common theme in MVC. It is important that these are independent of the UI world - these are not mouse clicks and what not but a view-specific language of events. This brings us to the next point.
The view does not depend on the controller in any way. Controller's are responsible for arranging and creating views and providing the interface between the rest of the world and the view.
In a perfect world, the view is responsible for making the model representation visible. This is how it worked when MVC was applied to desktop applications.
The reality is that MVC has been twisted and rewritten for the web world. It's not really MVC anymore or maybe MVC was simply redefined. This is why you are seeing so many different opinions and representations of MVC out there. If you are looking into writing desktop style applications, then look at the stuff by Krasner & Pope. If you are looking into how MVC is applied to the web, then I recommend Uncle Bob's keynote for an alternative that it better suited for web applications - what he called the Interactor, Entity, Boundary Architecture for lack of a better name. Dig around for stuff associated with his talks about "the Lost Years of Architecture".
Right now, I'm working on my first WP7 app and have run into some questions, which I haven't been able to answer despite reading what I could find online. Please consider an app that has a main page, a parameters page and a results page. In the parameters page, the user can enter or update numbers in various textboxes. Hitting the back button takes the user back to the main page, where there is a button called "Calculate". Hitting that button should take the data, perform a calculation with it and take the user to the results page presenting a grid with the results.
In a file called Calculator.cs I have a class called Calculator inside a folder called Models. I also have my MainViewModel.cs, ParametersViewModel.cs, and ResultsViewModel.cs files inside the ViewModels folder and the corresponding MainPage.xaml, along with Parameters.xaml and Results.xaml inside a folder called Views. I'm assuming that all the data will be manipulated within the instance of the Calculator class and then a results set will be returned and directed to Results.xaml. I'm just at a loss as to where to instantiate the Calculator class, pass it data, then retrieve the results. I'm also somewhat puzzled how I will trigger the automatic navigation to the Results page when the calculation is done.
Any help with this would be greatly appreciated.
UPDATE: Passing a complex object to a page while navigating in a WP7 Silverlight application has some more info on the same subject. I can go into App.xaml.cs and add something like this:
public class Foobar
{
public string barfoo = "hah!";
}
public static Foobar myfoob = new Foobar();
Then access it from a ViewModel page, e.g. AboutViewModel.cs, like this:
public AboutViewModel()
{
string goo = App.myfoob.barfoo;
}
But at this point I'm still uncertain what unforseen effects that might have. I'm going to tackle serialization/tombstoning at this point to see what happens with either this approach or by using the same DataContext across pages. Otherwise, one of the posters in the link above mentioned serializing the params and passing them between pages. My concern there would be whether or not there is a character limit as with HTTP GET. Seems there is: URI Limits in Silverlight
There are of course lots of possible designs - and lots of them are correct in different ways!
Here's one I might use:
The Calculate button press should trigger the Navigate to the Results page
On navigate to, the Results page should show some animation (maybe just a progress bar)
On navigate to, the Results page should create a new ResultsViewModel, passing in the MainViewModel as parameters
the constructor (or some init method) of the ResultsViewModel should spark up a thread to do the calculation
when this calculation is complete, then the relevant properties of the ResultsViewModel will get set
at which point the databinding on the Results page will clear the animation and show the results
Other solutions are definitely available - will be interested to read what other people suggest and prefer.
As an aside, one thing to watch out for on your Results page is tombstoning - could be an interesting challenge!