I have a mobile application that I want to try and reorganize so that it's easier to read and update and follows better practice.
I want to implement an MVC pattern, but I'm getting a little tripped up on getting there. I'm just hoping for some help with rebuilding the architecture.
Here's the outline of my application:
Level1) MainView has a column of 5 buttons that when clicked lead to View1, View2, View3, View4 or View5.
Level2) Each of these views is the same: a list, but each is populated with different data. Selecting an item brings the user to another set of views SubView1 - 20. that each are again populated with a list.
Level3) However, any selection made on a List in a SubView leads to a view that is always the same for all selection paths - but is populated with different data. Basically a button, another list, a text input and a textarea.
From what I gather, I should be able to use a lot less files and achieve something of the same result:
The model being a single class for data? The controller being a class or that controls the business logic, and a view that calls the controller?
Any suggestions, ideas and points in the right direction are greatly appreciated.
I'm guessing you'll be doing this in Flex4 and incorporate MVC pattern to some extent while doing so.
Have you looked into Cairngorm?
http://en.wikipedia.org/wiki/Cairngorm_%28Flex_framework%29
Related
Ok, it's pretty simple with a storyboard to have one viewController create a segue to another viewController. Simply control-click and drag from one viewController to the other.
How do I create a segue, either in the storyboard, or programmatically to invoke or present another instance of itself?
Why would I want to do this?
I currently have a viewController with a UICollectionView presented from data in a simple one-dimensional array of objects. When I select an item it presents a detail viewController for that item.
What I want to do is modify my data for organizational reasons to allow the objects in the array to hold an array of objects like the original data array, as a folder with sub-folders. It seems reasonable to me that simply updating what the data source is pointing to, and calling the same viewController itself to display the next level should be relatively trivial. When finished, simply pop back a level and be right where you left off.
It seems nontrivial to click-drag from the viewController to itself. Prior to using storyboards and segues, this would be done by simply presenting the view contoller. What is the best way to do this with storyboards and segues?
Yes, it COULD probably be done by manipulating the data source and just redrawing the current viewController, but it seems like it SHOULD be cleaner to just call the viewController with a pointer into the sub-array as if it was the top-level array and re-present the same viewController, letting the view controller stack manage the individual levels without having to redraw the model from different starting points and remembering the starting points in some kind of stack.
Any advice on the best way to do this?
Apparently you cannot invoke or present your view controller on itself.
Likely this is because UIKit is not re-entrant or thread-safe. So, Apple doesn't let you use a segue, or use presentViewController with an argument of self (or anything that resolves to self).
A pity, since it would have been nice to not have to create a sub-view contoller which does all the same things the viewController does.
If someone knows of a better way to do this, please post below.
I am struggling myself thinking about which component to use in my new app.
The first screen I am using Collection View with big images. Once the user touches one cell, it goes to the second screen ... and here is the problem.
I have three columns, similar to a dictionary with first language, second and third. The user will be able to choose which column he wants to search, and according to his criteria it will show the result that matches. I am not sure how to implement this, which component gives the best experience to the user. Any idea is more than welcome. Thank you in advance. Alex
If your data is several rows each with 3 columns, I would recommend customizing a UITableView. I followed this tutorial when I was trying to set up something similar.
The Table View will also give you efficiency if you have a lot of data, and you can build the custom table cells in the interface builder so that makes life a little easier.
-Ken
This is a really basic design question, but I can't seem to find an answer. I'll use a really simple example, but my concern is for cases where the model-level calculations, "2+2" in this example, become complex.
Let's say I'm designing an application to run in Zope or Plone; its job is to add two numbers. Dexterity lets me easily create a content type with fields addend1 and addend2, and will generate add, edit, display forms for me. I could modify the display form to also present a field named "sum," but "sum" is a result of extensive calculation in my model, and I don't want to present it in the "add" or "edit" forms because I don't need that as input, just as a result of calculation. I don't want to calculate it in my view, because it's expensive, I'd like to reuse it after initially calculating it, and I don't want my "view" to need any knowledge of how I do my calculations anyway.
So what is the proper "zca"ish approach for doing model-work that has nothing whatsoever to do with presentation of results? Do I create an interface like ISum and create an adapter that converts my content type to one including a sum, then do a view for the ISum interface? If not that, what? Searching PP4D and the Zope 3 Developers Handbook hasn't helped.
Thanks in advance for any insights.
Use events; you can register event handlers for when your content type is added, or edited, and you set the value on the object whenever these events trigger your handler.
Most MVC tutorials I've been reading seem to create 4 View objects for each Model. For example, if my Model is "Foo", there seem to be 4 .cshtml files: Foo/Create, Foo/Delete, Foo/Details, and Foo/Edit. Using the VisualStudio "scaffolding" helper does this as well.
Is this really considered MVC best-practice? It just feels wrong to have 4 classes that are 80-90% identical to each other. When I add a new field to Foo, I need to edit all 4 .cshtml files. This sort of dual-maintenance (quad-maintenance?) just makes my OO skin crawl.
Please tell me: is there an expected/accepted best-practice which handles this differently? Or, if this really IS accepted best-practice, tell me why the quad-maintance shouldn't make me squirm.
I'm a reasonably skilled veteran of ASP.NET / c# / OO Design, but pretty new to MVC; so apologies if this is a noob question. Thanks in advance for your help!
Edit: thanks for all the replies! I marked the most thorough one as the answer, but upvoted all that were helpful.
You'll probably need between two and four different views:
List (for viewing many things)
View (for viewing a single thing. Might not be necessary, if it's OK to use Edit as View, or if List has room to show all properties)
Create
Edit (can be the same as create, if you code cleverly)
Thus, if your model doesn't have too many properties to show them all in a table, and if you're OK with not having a static, non-editable view for just examining, you can get well away with just List and Edit, and scrap the other two.
However, this doesn't solve your problem of double (or triple) maintenance if you update your model. There's other magic for that ;)
In ASP.NET MVC 3, there are extensions on HtmlHelper that let you do Html.DisplayForModel() and Html.EditorForModel(). These use predefined templates to nest themselves into your object and draw up display/edit fields for all public properites. If you pass DisplayForModel an IEnumerable<Foo>, it will create a table with column headers that are the property names of Foo (using the DisplayName attribute information if you supplied it) and where each row represent one Foo instance. If you give EditorForModel a Foo, it will create a <label> and an <input> for each public property on Foo.
All of the templates used by these powerful extension methods can be replaced by you, if you're not happy with the defaults. This can be done either on the level of Foo, in which case you'd be back in your double-maintenance scenario, or on lower levels (such as string or DateTime) to affect all editor/display fields generated with the templates.
For more information on exactly how this works, google "ASP.NET MVC 3 editor templates" and read a couple of tutorials. They'll explain the details much better than I could.
The views that ASP.NET MVC create for you don't necessarily need to be the views that you use in production. I found those just to be handy while developing quick prototypes or to test the database CRUD operations. Feel free to create whatever view(s) you would like to handle the operations.
I would generally just have 1 or 2 views to handle the basic operations and not use the built in views that are generated. For example, 1 view for adding, editing, or details and 1 view to show a list of objects.
It all depends on your application.
If you have a single item, you don't need a List view. If you can't edit it, then you don't need an edit view. Create and Edit can often be the same view, unless there are special things you need to do in one, but not the other.
In other words, use as many views as you need. There's no hard and fast rule here. The scaffolding is just there to help you on your way. Many kinds of apps will work just fine using the scaffolding, and won't require advanced HTML or Javascript.
Why would you want multiple views? Well, let's take the display and edit functions. You could create one view, in which you use if statements to determine the edit mode of the view, however this will complicated the view logic and views should be as simple as possible.
The reason to create seperate views is that its easier to maintain than one gigantic view with tons of conditional logic in it.
You can use exactly the same view when you are performing [HttpGet]. Given that you pass a proper ViewModel to this view, it will populate with appropriate data every time whether you are loading create, update, or delete Action.
The problem becomes apparent when you try to post that data to a specific Action.
Naturally View should have only one form, which will be used for posting data. When you declare this form, you specify which exactly Action to use for Post.
Having 3 different Submit buttons in that form will not make a difference since all of them will post the same form to the same Action.
You could do some javascript tweaking on OnClick event for these buttons to change Action to which data is posted, but this definitively would not be best practice.
Buttom line: having 4 different views for each of the CRUD actions is the best practice for MVC.
I tend to create the following for an object's CRUD ops:
index
_form (partial)
new
update
delete
view
As the same form is shared between new and update, there is very little difference between the two. It really depends on how much you want the variation to be, honestly.
As for delete, this is optional. I like to have a view in case javascript is disabled.
edit:
You mention view models and the guy above posted a long, convoluted (no offense) VM code sample.
Personally, I hate classes written to basically mirror domain objects and are only used to "move" data. I hate VMs. I hate DTOs. I hate everything that makes me have to write more code than is necessary.
I guess I've drank the coolaid of other frameworks (rails, sinatra, node.js) to the point where I can't stomach the idea of tossing DRY to the wind.
I personally say skip um.
Edit2 I forgot list..
I have a checkbox in a Flex DataGrid, and when I scroll, other rows are randomly checked/unchecked.
After reading over: Creating a column of RadioButtons in Adobe Flex
it's clear that the itemRenderers are getting recycled, but the problem I have with the solution presented there is it moves info about the view into the model.
Does anyone have a better way of solving it, that doesn't force me to put information for the UI into my actionscript model classes? (in my case, I am converting incoming XML data to actionscript classes, and these are getting bound to my datagrid).
Thanks for the help.
thanks everyone. great tips. unfortunately it was becoming too much overhead to keep the model pure, so i just polluted the model like the link in my original post. :( at least it works.
Chetan, neat idea.. i tried working with this for almost an entire day with no luck though.
brd6644, good thoughts on separating the two model classes.. i might go back and do this later.
You could create a subclass of DataGrid that internally stores what rows are checked/unchecked (Array/Collection of Boolean) but you would have a devil of a time keeping that in sync with the dataProvider when it is sorted or filtered. I suppose you could use a Dictionary that is keyed by the object in each index of the dataProvider and valued with a Boolean to indicate whether it's selected. That would at least isolate you from the sorting / filtering issues. This will not work if you have duplicate references in your dataProvider.
Alternatively, you could create a subclass of your ActionScript model class and add the "selected" property to it, then write some simple utility methods to "convert" between the two. That way your View deals only with the "ViewModel" class and other layers (especially the server side) deals only with the real "Model" class.
Adding to what cliff.meyers said, there is a third option of creating a custom IList class as described in this blog post by Alex Harui. It is pretty clever actually, and is cleaner as it doesn't require subclassing the component or polluting your model classes.