How in an ExtJS 4 MVC single web page application we can identify Views?
Is it a good practice to consider each Ext.Window as a View unit? (one folder for each Window in app/view folder)
What is best practice?
Using single folder for each Window could be a nigthmare.
The concept is not for each window but for each entity (or model).
Having a folder for each model's views is the point.
For example, you have 3 entitites (models) in your application, sat Customer, Invoice, Payment your should have 3 subfolders in view main folder, one for each model. Inside each folder are the views used for CRUD for each model: List and Edit. If you have another views for the same model you should put in their respective folder (inquiry, charts, etc.).
I been working in a payroll application and my rule is use soubfolders as packages as I do in Java. I group related views in the same "package" even if is not for only one model. For example, I have a folder for all "catalog" models (depts, jobs, etc.), another for payroll processing and so.
The MVC of ExtJS is very similar to Ruby on Rails.
Regards.
You should read these before starting your application
http://www.sencha.com/forum/showthread.php?131671-Advanced-MVC-Best-Practices
http://www.sencha.com/learn/architecting-your-app-in-ext-js-4-part-2
Related
I am currently creating a small Laravel project. The goal should be.
Every User can have 1 or more projects. Every project has data that displayed in Datatables.
The Problem. The data for each projects are different in structure (e.g. Addresses, Questionnaire, ...)
I have now created a separate model / view / controller for each project. But I think it's not the right way. e.g. 100 users have 2 projects, then I need 200 model / views / controller ???
How could I do better?
Thanks in advance for your help.
Currently I'm using resources files to localize MVC4 project in a standard key/value way. I'm now looking into best solution to separate some keys based on controller/action they belong to. There is always raw solution in creating keys such as Home.Index.Title but that's just workaround. Is there a way to work with resx files where they could be designed with parent/child nodes, where highest node would be Controller, then Action and finally Field, so that they can be queried by LINQ?
Resx files always have a simple key/value structure. If the aim is to organise the resources and make them easy to locate for maintenance, I can suggest a couple of other approaches.
If the resources in question are for use in views, you can create one resource file per view in an App_LocalResources folder within the view folder and organise them that way, indirectly linked to a specific controller and action.
If the resources are for use in the controller itself, you can create a set of folders within (say) a ~/Resources folder that represents the controllers and within each, a resource file for each action. That way, the resource namespaces will indicate the controller/action where the resources are consumed.
I have been doing a lot of research on MVC and file structure. Mainly I've been looking at how to start a new layout. I have downloaded a few open source applications to take a look at file structure and how files are developed.
In the first application it was set up to use the standard way (at least the way it seems to me) of putting all the controllers, models and views each in their respective folders. This is the way that all the books say to do it.
In the second application, all folders are in a modules_core or modules folder where each controller (at least what I would assume to be controllers) are in a folder in there that contain three folders: controller, model, view.
Which of the two versions is accepted as standard and common practice? Are the two applications different because of versions of Codeigniter?
The standard of Code Igniter is to use those three folders:
Controllers
Models
Views
You can also create sub folders to better separate your files.
Searching a bit, I found that MyClientBase use something called codeigniter-modular-extensions-hmvc that is like a extension for CI.
Modular Extensions makes the CodeIgniter PHP framework modular.
Modules are groups of independent components, typically model,
controller and view, arranged in an application modules sub-directory,
that can be dropped into other CodeIgniter applications.
HMVC stands for Hierarchical Model View Controller.
I don't have experience with hmvc so I cannot tell you what is better. For the standard CI structure, try to separate well in sub-folders (controllers, views and models) related files and try to use helpers to better reuse your code when you need to use functions in more than one place.
I think MyClientBase (which seems to be far from the "standard" exemple), seems to be using HMVC more then MVC.
I'd just like to get some clarification in the MVC pattern as to what belongs in Models, specifically the contents of the Models folder in MVC3, versus repositories and objects.
Right now, in my current MVC3 Solution, I have 4 projects:
A Project called "Objects", which holds information about all the core objects in my application.
A Project called "Data" which holds information information about the Data Context and repositories for each of the objects (created using MVC3 scaffolding)
The Web project, which holds the Controllers, Views, and -- the subject of this question -- Models
A Unit Testing project
What I really would like to get clarification about is the difference between what should go in the Objects project vs. what goes in the Models folder of the web project. Right now I'm only using the Models folder for holding what I'd call "View Models", which typically contain combinations of the core objects. Should the files in this folder only contain definitions defining the model contents, or should it contain other code that the controller may call?
I think that I have a pretty good understanding of both controllers and repositories, but sometimes I get confused as to whether certain code should go in one or the other. Are there any specific guidelines or limitations out there as to what absolutely should NOT go in a controller but should go in either a repository or a model instead?
Thanks as always.
We do something very similar except that the Objects and Data are combined in a Core library which is referenced by all projects. The models folder in the MVC project is strictly for View Models.
If your controller require additional classes, it really depends on what it needs as to where it goes. I will typically include a Helpers folder with subfolders for HtmlHelpers, Attributes and Filters. If it's a dependency that makes sense to exist outside the MVC project (common classes which are used across all projects) I'll add it to Core.
I am delving into custom validation attributes and am curious to know how others structure the projects. Where do you typically store custom attributes?
My first thought was to simply create a new folder and be done with it.
Any suggestions?
My first thought was to simply create a new folder and be done with
it.
It would depend on the nature of those attributes and what thety are supposed to do. For example if they are validation attributes you could put them into a Validators folder. If they are action filters you could put them in the ActionFilters folder, etc... so your initial thought is correct. Personally I group those attributes based on their function and place them in a separate folder which indicates this function.
I use 2 different approaches.
Set up a common Class Library to store common validation that will be used on many MVC applications. Then reference this library from your MVC application. You can use http://dataannotationsextensions.org/ to view the source code on how to setup this project.
Place them in folders as suggested by Darin. This folder would be used to store custom validation. If you app was used to keep golf scores a custom validation only to the application could have something to do with a handicap calculation or something specific.
Thanks,