I use the MVP pattern in my project. According to it Place define view after a new Activity starts. In some cases when I have to save the content of some Text areas after change of Place. I think that it is not a good idea to put these text areas in Place, because they don't define business logic. To save them in View elements is not good either. How do I resolve this situation?
GUI elements (GWT widgets) belong in Views. Why do you think otherwise?
Then your View interface (or is it Display?) can have getTextData()/setTextData() methods to retrieve data in your TextBox.
Related
Sometimes having to create controller, registering it in widget and then registering listener in controller looks like overengineering. I'm trying to understand why Flutter Team decided to go this path for some widgets, i.e. for text field, list view, while for others, i.e. for button widgets we can simply register onPress listener right in the widget itself, which obviously is easier and requires less boilerplate code.
Any reason why having controllers is a better thing compared to simple event listeners?
Controllers are used to store state higher up in the widget tree so a parent widget can both react to it as well as change it.
In the case of a text field, it wouldn’t be convenient to have a callback when a user presses a key and then have the parent construct the new text that should be displayed and rebuild the text field with that. (And it is not just key presses because you can paste text as well.) So the text field stores the text, so it always knows what to display and the onChange callback can report the whole text after the user changes it.
But then you might want to change to text from the parent as well. They could have made it such that the parent would have to rebuild the text field with a new text in such as case. However, for some use cases where you don’t just want to overwrite what a user typed, the parent would have to stored the text as well. Which would duplicate the state.
In the end it is simpler to have the controller own the state (the text) and allow both the parent and text field to change it and to read it.
For a ScrollController the situation is similar: both the scroll view and its parent might want the change the scroll position. And both might want to read it (surely the scroll view does).
Another advantage of the controller pattern is that the “parent” could be several widgets higher and you’d only have to pass a single controller through the intermediate widgets instead of several callbacks and several pieces of data.
I think this is because of 1st principal of S.O.L.I.D. which means single responsibility. Each object should be responsible for its own specific functionality. TextField serves text input, ListView serves item browsing nothing more. If you need some other (optional) data you need to ask someone other who responsible for it. Indeed, it is a controller.
From other side this approach gives some flexibility. You may change controller on runtime.
Can we Add a selection provider to a view that contains only widgets?If so how What should be the setSelection's Parameter.
This totally depends on the kind of implementation that you have done. If you are using widgets as some kind of select-able entities in the view then you can provide setSelection implementations.
The setSelection takes an ISelection instance, and it can contain any kind of object. So for example if your view has a form, with many labels and editable fields, you might want to "set focus and scroll to" any of the fields depending on the situation from the outside programmatically. Your setSelection would receive an object (maybe just even an integer index) wrapped in a ISelection object. It would be up to the implementation of the setSelection to move focus to the specific control and scroll to it.
I have a panorama app that has two panorama items so far, "recent" and "popular." These get populated with data using binding from a viewmodel. I would like to add a third ("search") panorama item that initially shows just a text box and a button.
When the user inputs text and clicks on the button, I want the text box and button to be replaced with the ListBox control that shows the search results.
I cannot find any examples on how to do this using the MVVM pattern. I am not using a MVVM framework and would like not to since I am just learning all this.
If you can explain or better, point me to examples that will allow me to do this, I would very much appreciate the help. If I left out any required info in my request, please let me know.
Sincerely,
Kamal
Typically for something like this you would have a property in your ViewModel that would tell the view what to show. You have lots of different options for how you could do this.
One option would be to have a Results property that your list box is bound to. Put the textbox and button in a Grid and bind the Visibility property of the grid to a property that is Visible is there are no results and not visible if there are.
Lots of different ways to do this.
Examples here and here.
You could probably bind a list of a custom class to the panorama ite .
The custom class contains a title and/or description and a page class.
You can maintain your views in your main viewmodel.
Another solution would be adding the items in xaml and using the same viewmodel for the whole panorama item control. With a property you can control the visibility of each item.
Like Bryant said: there are so many solutions. It depends on your application and requirements... :)
I have been following the GWT MVP tutorial (https://developers.google.com/web-toolkit/articles/mvp-architecture-2) and while it all makes a lot of sense, I have some trouble taking it from the example they explain to a larger scale application.
In particular, I would like to use a DockLayoutPanel to have a separate navigation, content and header section. What I'm struggling with is primarily the question of: where does the main dock panel live? Is it a view with it's own associated presenter? Does it constitute a special case where I don't want to use a view as this is really just the fundamental page layout?
It would be greatly appreciated to get some practical insights from people having faced a similar issue before.
Well I think as always it depends.
But I would recommend to create a View (i.e. MainPageView) with it's own associated Presenter (i.e. MainPagePresenter) even when there is almost no business logic and the View only defines the layout of the application.
Maybe in the future there will be some business logic.
For example if you want to show alerts or notification popups to a user you will probably do this in this View.
So your MainPagePresenter will listen for Notification events on the global EventBus and once an event is fired from any nested Presenter it will display a notification popup in the MainPageView.
Another use case would be if you want to display breadcrumbs in the north panel.
Of course you could create a separate Presenter for breadcrumbs but IMHO that's too much overengineering. You could however easily do that in the MainPagePresenter
I am using GWTP as my MVP framework and there it is really trivial to create View/Presenter pairs and it also supports nested PresenterWidgets which you can for example embed in any panel of your DockLayoutPanel
After searching for something related, I stumbled across another thread that asks a similar question and was quite insightful for me:
GWT MVP - maintaining multiple displays that are separate of one another
I'm really struggling with a choice between the GWT Tree widget, which has been a part of GWT for ages; or the new CellTree, which is introduced by GWT 2.1.
The tree I want to present to the user is not particularly large, but I am very concerned about responsiveness.
The data at the nodes of the tree will be editable. By clicking on a node, the user will put the node into edit mode. Editing the more simple nodes will require only a single TextBox or TextArea; but others will involve several widgets, over which I want styling control via CSS.
I'm attracted to the CellTree approach because it seems to offer great flexibility and speed; however, the sample code for CellTree editing deals with only very simple data types: string, date, integer, etc. I don't know if CellTree is appropriate when you've got more complex node-editing needs.
What do you think? Is CellTree the best approach? Does CellTree replace Tree in general? What heuristics can I apply in choosing between them?
I'm using a CellTable with several custom input Cells, including one comprised of many widgets. It works great!
It took me a couple of hours to understand how to implement a custom Cell that could do complex operations - since a single instance of the Cell will flit around the CellTree, pretending to be many instances, you need to understand how it's getting its data and when it is refreshed and rendered. I learned a lot from the source of the DatePickerCell.
I can't speak for CellTree, but the CellTable is very flexible, was easy to program, and saves me hundreds of Widget instances.
Using CellTree is problematic. Because it hasn't good access to view implementation stored in CellTree. It cause problem (ex. for me :D) in making custom handlers for opening nodes with children by clicking on whole parent cell. Of course you can make custom cells by AbstractCell, where you must write own renderer.
I think this widget must be enchanced and more objects must be more visible for users.
Customizing CSS is simple. All what you have to do is extende CellTree.resource and insert own css based on celltree.css class names.