I have an application in which I would like the user to 'save the view'. I.e. I make heavy use of ajax to replace all kinds of Panel and use nested jQuery UI Layout plugin for 'frames'.
So basically, the view is defined as the (functional) tree of components, combined with the Javascript state of the jquery plugin, combined with the 'query' a user has given.
I'm wondering what would be a good strategy to save this view state, and how to load it again.
I though of keeping a sort of UIState-model on the page level, and pass it to all components. The components then use specific settings of this model to initialize themselves and changes in the components should be reflected back into this state model.
However, this gets complicated when a Panel is reused in several places. The reason is that a component needs, besides its knowing how to read its own state from the central modal, also take into account the location in the (functional) hierarchy of components.
What would be a good approach? Has anyone done something similar?
Related
I have a Kendo UI application flow where I don't want the user to be able to step back into a particular set of views (ie, a couple of 'create' views that lead to the 'completed record' view - the user should not re-access those specific create views). This is for a mobile app if that makes a difference.
I know that Kendo can use window.history features to some degree, but it looks like they have only implemented pushState (http://docs.telerik.com/kendo-ui/api/javascript/router#configuration-pushState), but I believe I would need the replaceState method.
Is there a way to take some manual control temporarily without breaking off from the back stack/backbutton widget?
Turns out that Kendo has an implementation of replaceState that they have abstracted to replace. See doc here.
It's as simple as calling your next destination.
kendo.mobile.application.replace("#baz");
kendo.mobile.application.navigate("#baz");
All, I am new to Windows 7 Phone. My situation is that I have a main page which contains a ScrollViewer which in turn houses a StackPanel. I want to populate this StackPanel with multiple sub-StackPanels (at runtime) which are to hold an Image Thumb nail a hyperlink and some basic information about the image.
This is all good when I do this from the main page, but I want to know how to update this control (which is on the main page), but from any page other than the main page. I would like to know what is considered best practice for updating a page's control (like that outlined above) from another page.
Obviously there are a number of ways to pass data between pages
PhoneApplicationService.Current.State["yourparam"] = param
NavigationService.Navigate(new Uri("/view/Page.xaml", UriKind.Relative));
then in other page simply
var k = PhoneApplicationService.Current.State["yourparam"];
and many others. But what is best practice for updating a generic control from a different page?
Note: There are many question about data access and passing between pages.
Passing data from page to page
How to pass the image value in one xaml page to another xaml page in windows phone 7?
Passing image from one page to another windows phone 7
and more. This is not what I am asking.
If I understand your question correctly, you are trying to update a control which is on for example MainPage.xaml from another page for example Page2.xaml.
As far as I know there is no way to reach a pages controls from another page, and that seems unnecessary for the cases that I can think of.
The method used to achieve what you are trying is usually done by triggering an action (like the press of a button ) and passing a parameter to the page you are trying to update the control. And on that page's onnavigatedto event (or viewmodel constructor if you are using the MVVM pattern), update your control based on the passed parameter.
If your update is based on data then the best practice is to bind an observable collection or an object that extends the INotifyPropertyChanged (basically any object that can signal that one of their property changed to the ui) and change the data based on the parameter that is passed.
If these two pages somehow are visible at the same time and there is no navigation needed between them( like a popup or sliding menu kind of ui) then you can make the page that you are showing in the popup a usercontrol, and reach to the parent's controls by this.Parent.
I can be more helpful if you give more specifics about your app's flow.
The MVVM pattern would be a good way to go. Saying MVVM is too complicated for small teams isn't exactly accurate - the purpose of MVVM is to decouple Silverlight or WPF code. Using the codebehind of a Silverlight page to directly access data creates coupling in your code and accrues technical debt. Whether you're one developer or 100, if your UI is coupled with your data classes, if you have to change your data classes, you will have to make changes to every UI element that uses those classes. This takes longer and makes your application more difficult to change.
MVVM makes it so your UI (the View) doesn't know anything about the data (your Model). The ViewModel is the code in between that the UI can bind to, and which manages events in the UI that need to be persisted to the Model, and also changes in the Model that need to be represented in the View. For this reason, it handles events, and that's what it sounds like you need in your code - an event that can exist off of the codebehind, that can update the Views bound to it when the data changes. If you have two pages, then an event on one of the pages will be sent to the ViewModel, which will make a change to the Model (data) if necessary, and pass it back to the ViewModel. The ViewModel would then update any of the UI elements (Views) bound to that piece of data.
There's a REALLY good demonstration of how to implement the MVVM design pattern here
. The guy goes through and takes a typical WPF application (just like Silverlight), where the UI codebehind implements event handlers that directly access data, and refactors it using the MVVM pattern.
Here is an issue I've confronted in multiple user-facing applications: a program contains components for graphical rendering of data, (call them views) and other components for managing those data (call them models). Some of those data are in the form human friendly text, often key value pairs such as
System Load: 20%
Running Time: 20mins 30sec
But which software component should be responsible for constructing the text strings? You could argue
The model: should choose the text while leaving the view to display it. This way the views don't have to know exactly which data are provided, and (probably) lets the model expose only a small API. Also it means that the text stays consistent across multiple views (or UI toolkits). This ways views don't have to worry about i18n.
The view: should do it because this is a UI issue, not part of the business logic. After all, the choice of text is not always cleanly separable from rendering. This way models don't have to worry about i18n.
How should I settle, or think about this division of labour? Any ideas?
Note 1: I don't think this issue is restricted to MVC designs, although that's where I get my terminology.
Note 2: While researching this question I stumbled across Presenters, and ViewModels. Are they supposed to do this kind of work, and when is such a proper/complicated solution worthwhile, and when is it OK to just do it in the Model or View.
Taking this from an MVC perspective, if I have data to display in my view I will (almost) always create a viewmodel which the view inherits from, with the viewmodel properties of the correct type for the data. e.g. in your example above I would have SystemLoad as decimal, and running time as a number of seconds. I believe it is then the responsibility of the view to determine how that data is displayed (how the user VIEWS it).
Using the ViewModel approach makes it very easy to define multiple views to represent the same data. A controller need only know to supply and receive a specified class - the ViewModel - which can then be passed to whichever the most appropriate view is to be rendered. This rendering could be rich HTML for full browsers, stripped down for mobiles, or even a JSON response for an API, either way the controller need not change.
WRT to the original question, this is just an example of justification for leaving the formatting to the View. Whether you use viewmodels or not, this logic does not belong in the controller
As a general rule I would suggest leaving to models anything that is abstract and to the view, all the specific. For example, a model would have system_load: 0.20 and running_time: 1860 but y our view would turn these two values into actual useful, viewable information.
I am designing a web application with a left sidebar. Each of my actions has its own widgets which must be loaded into the sidebar, and in some cases multiple actions are stacked using the Action Stack plugin. When all actions have finished running I need to 'normalise' and manipulate the number of widgets, then render them.
At this stage I am thinking that:
Each action should store its list of sidebar widgets with the view, and
A front controller plug-in with a dispatch loop shutdown event should take the list from the view and operate on it
Does this sound reasonable? Is there a better way?
I wondered whether I should be storing the list of sidebar widgets with the response object directly, but I don't think this object allows user variables, does it?
Your thoughts are much appreciated! Yeehhaa!
Ok, so I ended up defining a list of widgets in an array for each controller, then modifying it where required in each action. But now I am in the process of moving more logic into the model, so no doubt will all change.
I have been reading about the evils of the ActionStack and now that I have my head around how to go about things without the action stack, life is much simpler!
I'm developing an app which has a large amount of related form data to be handled. I'm using a MVC structure and all of the related data is represented in my models, along with the handling of data validation from form submissions. I'm looking for some advice on a good way to approach laying out my controllers - basically I will have a huge form which will be broken down into manageable categories (similar to a credit card app) where the user progresses through each stage/category filling out the answers. All of these form categories are related to the main relation/object, but not to each other.
Does it make more sense to have each subform/category as a method in the main controller class (which will make that one controller fairly massive), or would it be better to break each category into a subclass of the main controller? It may be just for neatness that the second approach is better, but I'm struggling to see much of a difference between either creating a new method for each category (which communicates with the model and outputs errors/success) or creating a new controller to handle the same functionality.
Thanks in advance for any guidance!
My preference would be to create triplet Form-Controller-Model for every form displayed to the user. Whenever user clicks on 'Next' button on a form its controller should talk to the back end manager which takes care of dispatching submit request to the next form in chain. Vice verse if 'Back' button is clicked. Last form has a 'Finish' button which will go to the manager and pass the last bits of information.
This will avoid inheritance, make your code more robust and testing of forms possible in isolation.
My preference would be to keep it all in one controller. It keeps all the relevant processes for filling out the application/form in one place, although I'm not sure how "massive" you're talking about. If you do decide to split it out, I would not subclass off of the main controller, but just make a handful of independent controllers, perhaps related by name for ease of use down the road.