I have an ExtJS 4.2 Application with the following structure:
I'm going to start a new ExtJS 6 application and will move by hand all resources.
I have read that in ExtJS 6 the traditional MVC structure (like I have in 4.2) is not supported so now I have a a View and under my view a have a ViewController that will handle all the logic for that view. Is that correct?
Does ExtJS 6 support my actual structure?
The traditional MVC structure is still supported. In fact, it's still the recommended way to deal with a controller that spans multiple views.
However, it's not the only way anymore. The ViewController is intended to work with a single view, and to encapsulate logic common to, say, a classic & modern version of a view.
Your structure should work, subject to any actual API deprecations. I converted a 4.2-based app to 6 that used a similar layout.
Related
Background:
We're using Caliburn.Micro 3.0.0-beta2 with a WPF + Xamarin iOS / Android project and we want to ensure the view models can be cross platform to reuse as much code as possible.
We've been looking at how to abstract our our navigation to be testable, cross platform and so callable in the view model rather than the views.
I was wondering if anyone had suggestions about how we should handle our app navigation. Our screens require us to inject some data such as database ID's into screens as we're navigating around. Currently we've done this with a view first approach by injecting the data into the view and having that pass it into the view model, but this doesn't feel ideal as it should really go into the view model as it's view logic (right?).
The view model is created for the view view using ViewModelLocator.LocateForView(this); and this then satisfies the rest of our dependencies using the SimpleContainer.
We Understand that navigation hasn't been implemented into 3.0.0 yet according to https://github.com/Caliburn-Micro/Caliburn.Micro/issues/142. We're really looking for a way we could do navigation that may be similar to the Caliburn.Micro solution implemented soon, with a hopeful view to contribute towards this if possible.
Questions:
How would we go about getting the data into the view model rather than the view to make it easier to test and more similar to how our WPF application will need to work?
Is this even sensible for a mobile app or should we be taking a view first approach? If so, what would be a testable approach for this?
Unless you have setup Caliburn.Micro for view-first approach (can be done there is a sample for this) the framework is almost completely viewmodel first in nature. I find it rather difficult to work in view first. Most of my "screens" are developed around the view model in question. With that in mind I also at times have multiple views for each viewmodel depending on the operation (add/ edit/ details/ list) for example.
1) DI, usually through repository or other context of that nature then using BindableColllection to hold and notify of changes to the view. Pretty much the same as WPF would work. Most recently my code has started to be cross platform (WP to WPF, now more Universal) to help reduce my headaches. Most of the patterns used are DI(SimpleContainer), Repository (EF 6x), Pub/Sub (IEventAggregator). The one exception is Repository but to an extent I still use it on WP but since I use Sqlite, up until recently EF was out of the question (EF 7 to the rescue)...
2) Do what is comfortable. If you are use to using Fakes then do it. It shouldn't matter as long as you have the correct results you are looking for in the end. Of course I am sure each test is going to be slightly tweaked for the platform they are tested on. Since each platform has its own nuances that you have to take into account.
I have read Apple's MVC article and am confused about various things. Firstly Apple uses a combination of the View and the Controller in almost all its sample applications which is fine and I like it but they contradict themselves in this article because they said that View's should not rely on Controllers etc.
My main question is does anyone have a link to one of Apple's sample iOS projects which is a good example of the MVC pattern - with data retrieval etc because I don't fully understand the Model part of the pattern.
I don't understand the difference between a 'domain object' and a model object. For example if I wanted to retrieve a list of orders this would happen in a model class Orders. Would I then have another class Order which has properties such as OrderDate, OrderNumber etc or how would this work?
This sample code demonstrates a multi-stage approach to loading and displaying a UITableView. I think it's really interesting to dive in. It will show MVC in the works.
Here’s how the Model-View-Controller (also known as MVC) pattern maps to the main parts of your App:
Model → Data
View → User Interface
Controller → Core Logic
this explain fully with sample code
http://www.hollance.com/2011/04/making-your-classes-talk-to-each-other-part-1/
I believe that the following code will help you understand how to work with MVC in iOS application because its description says:
"MVCNetworking is a sample that shows how to create a network
application using the Model-View-Controller design pattern.
Specifically, it displays a photo gallery by getting the gallery's XML
description, thumbnails and photos from a web server, and uses Core
Data to cache this information locally."
http://developer.apple.com/library/ios/#samplecode/MVCNetworking/Introduction/Intro.html#//apple_ref/doc/uid/DTS40010443
The model is the brain of the application. It does the
calculations and creates a virtual world for itself that can live
without the views and controllers. In other words, think of a model
as a virtual copy of your application, without a face!
A view is the window through which your users interact with your
application. It displays what’s inside the model most of the time,
but in addition to that, it accepts users’ interactions. Any
interaction between the user and your application is sent to a view,
which then can be captured by a view controller and sent to the
model.
Controllers in iOS programming usually refer to view controllers. Think of view controllers as a bridge between the model and your
views. They interpret what is happening on one side (what the user
does on the view side, or the information provided by the model) and
use that information to alter the other side as needed.
This is by far the best, yet simple explanation I've come across(taken from RayWenderlich)
"The idea behind MVC is that
- VIEWS should only care about how they are presented HOW THEY ARE PRESENTED,
- MODELS should only care about their DATA, - and CONTROLLERS should work to MARRY the two WITHOUT necessarily knowing too much about their internal structure."
I have been using jqGrid as my grid view to my data for some time now. It works well and it was easy to implement into my solution. However, due to some refactoring going on within the project right now, I have been looking into it again.
The project itself is built around ASP.NET MVC 2 (.NET 4.0). We need some extra functionality such as:
Being able to add columns.
Inline editing of columns.
Sorting
Filter
Paging
Searching
jqGrid does all of this (although, not all of this functionality is implemented yet - some of it is new based on new needs). But, given that I am using ASP.NET MVC, I was wondering if it would make more sense to switch to the Html.Grid helper. It looks just as easy to implement for the things I know it can do (Sorting/Filtering/Paging), but I do not know if it can even do the other tasks (in a fairly straightforward manner) - anything I have found seems somewhat "hackish."
Can anybody enlighten me on A.) the capabilities of Html.Grid to jqGrid and B.) if there is any reason I'd want to take Html.Grid.
I use jqGrid successfully with ASP.NET MVC 2 (.NET 4.0) and have all the features which you describe in your question. Moreover all pages having jqGrid looks like very simple.
I don't use Html.Grid or any MVC controls. I include just pure HTML fragment <table id="list"></table><div id="pager"></div> on the page. Additionally I include the JavaScript which initialize the "list" table and the "pager" div as the jqGrid. So the implementation is independent from MVC concept. The most important part of the jqGrid integrations is the actions which get back pure JSON output and which implement GET/PUT/POST/DELETE operations with the jqGrid. You can read more about the approach here (see also many links with code examples included in the answer).
To be exactly I prefer to use WCF as a part on my ASP.NET MVC solution and the WCF methods provide the data needed for jqGrid (see here more details), but you can implement all as pure ASP.NET MVC actions.
If you use Unit testes for you ASP.NET MVC site you can successfully write tests for WFC methods or controller actions used by jqGrid. In the way you will test the most parts of jqGrid implementation.
After looking at both approach, I decided the jqGrid was a far easier (and simpler) approach for what I was attempting to do.
I need a very specialized CRM
Do I
I want to recode the entire layout of sugar crm. whats the best way to start.
write a separate application and update SugarCRM via API calls
Can you be more specific about "very specialized CRM" ?
1.) You can customize all the field, drop down menus, layouts using the studio.
Check out:
http://developers.sugarcrm.com/docs/OS/6.1/-docs-Developer_Guides-Sugar_Developer_Guide_6.1.0-Chapter%204%20Customizing%20Sugar.html
Since you have decided to use SugarCRM don't develop UI outside SugarCRM. Since SugarCRM is very extensible and basicly every view in it can be replaced with any smarty tempalte/html page then there is no reason not to use it's functionalities especialy something like privilidges, home dashboards etc.
So my answer is go with SugarCRM customization.
If you are looking to re-write the whole MVC architecture of Sugar, I would write your own system based off a PHP MVC framework like Zend or CakePHP, if you are just looking to create specialized fields, and maybe tweak some layouts or something, I would recommend SugarCRM, because created fields and adding them to a basic 2 column form layout is quite simple. Even extending the current views is pretty easy if you have a solid grasp of OOPHP and the MVC architecture. Without knowing all your needs here, I'd be very surprised if you had to write a whole custom system. Almost Everything can be extended and customized in an upgrade safe way, which leaves you open to gaining the benefits of the new SugarCRM releases when they come out with out losing your custom enhancements.
I am building a site in ASP.NET 4 and MVC2 that will have premium features, such as SMS notifications that will only be available to paid subscribers. I also have additional modules for things like Inventory, and Transactions etc
I am already leveraging the standard MembershipProvider, and am leaning towards using Roles tp provide this functionality.
ie: have an "SMSModule" role that the user gets if they pay for the add-on SMS service
This makes the controllers simple with a little attribute decoration, but the problem I see with this is that there will be a bunch of conditional code scattered through my views etc
Is there a better method of providing a "module" style approach in .NET 4 and MVC2???
You can add your conditional logic to view models, use the controllers to set the viewmodels appropriately and it should be fine... Sometimes you have to have the if statements inside the views even if not so ellegent. Unless of course you are using a view engine like spark then your if statements are placed in another unobtrusive location, but they still exist! You can always create HtmlHelpers and set the code to the serverside and based on the logic display appropriately...
FWIW I ended up using a combination of Descriptors in Spark View Engine, along with a custom Feature provider and associated ActionFilter