I'm trying to comprehend usage of MVC pattern for JS application in case of working with multiple models. For example, I have a page with user info, his orders and executors of order. I need to show some user info and make orders and executors editing. So I have 3 models and need controller and view for each. Besides orders and executors are in lists. All lists for consecutive use in models must be loaded from server. What approaches should I use to manage multiple MVC entities in one page? Maybe another design patterns, etc.
UPDATE
To clarify
But, if I need to make a separate page where I work only with orders or only with executors. It is logical that these should be separate entities so that they can be used in various tasks. I thought that, in this case, perhaps, it is necessary to assemble one "large" model from the "small" models to solve a specific problem, or to make some kind of interface for interaction between models.
What am I talking about? For example, when I load orders from the server, I also load some information about the executor, i.e. in a SQL database, this is done by some JOIN of two tables. Which of the models to make a request for loading? Obviously orders. How, then, initialize the executor model data? Okay, I'm doing one big model where are all data I need about all of the entities in my application.
Ok, the page (modal, whatever) for executor's editing. There is no need for order data or customer (user) data. For this I use the same model, where some of the data and functions associated with them will not be used. Something is not sticking with me :)
Just a correction, MVC is an architectural pattern and not a design pattern. However the 2 differ by a thin line so its very easy to mistakely interchange both during discussions.
Irrespective, MVC should be a good approach to structure your code:
- authentication [Feature1]
- pages
- signin_page.htm
- authentication.css
- signup_page.htm
- models
- user_info.js
- signin_info.js
- auth_controller.js
- orders [Feature2]
- pages
- models
- order_info.js
- payment_info.js
- order_controller.js
- Feature3
- Feature4
- shared [all common things]
- services
- http_service.js
- models
- error_info.js
Basically you can create a folder for each feature or functionality and then inside that on a need basis create folders namely pages/views and models and then 1 or more controllers for each feature and a single generic service to do http calls which should take parameters and url as input and should handle all the error handling.
Related
The question is about managing models in forms on client with backbone.js
There is a model User on the server. It contains various fields:
Personal info
Name
Last name
Date of birth
Other info
About me (text)
My hobbies (text)
I have a single page application of settings. There are two forms on it: "personal info" form and "other info" form. I although have an api, that contains two routes to handle it - /api/user/<id>/personal_info, /api/user/<id>/other_info (it could be changed, it does not matter). I can PUT or GET info from these apis.
So I can't decide how to organize my backbone models right. Right now I have two models - UserPersonalModel and UserOtherModel, each of them has it's own api and I save them apart from each other.
Am I doing right or I shall rewrite it to one js model UserModel and call different save methods like .savePersonal and .saveOther? What is the best practice?
This question came here from ru.stackowerflow.com
Unless you're displaying multiple user forms at the same time and you'll have to do extra work mapping each other_info model with respective personal_info, I don't see any reason to combine those two as single model.
Especially since you have two endpoints, it's easier to have them as separate models, you can have separate view controlling each forms with respective models as well.
Combining the models will probably create nested attributes, then you'll have to manage that as well (Using plugins like deep model).
I am working on a user group system. Each group has several features and I want to make the interaction with the group collection as secure and simple as it can be since it is still at an early stage.
Right now, I have a group section in my website where I use several nested pages. The purpose of the section is to allow the user to get in a group, request membership if the group is private, browse one group objects, etc.
For example, within my group section, I can load in the yield a "see all groups" page, a "create a new group" page or "see only my groups" (the ones I am member of) or a "view group" to get a group details.
My first approach was to create one controller.js file for each subpage, which call one subscription tailored for the subpage needs. For instance, I have an 'all_group' publication/subscription for the "see all groups" subpage and a "my_groups" one for the "see only my groups" subpage.
But this is becoming really messy. Additionally, I declared my "group" collection in the both folder, so I am not sure to follow where the data available to the client comes from.
Now that I explained the situation, here are my questions:
when I do a console.table(Groups.find().fetch()); on client, I see fields that shouldn't be there (i.e. not returned by my current publication or any other). Is that because I declared the "group" collection on client side? How to fix that?
Should I get rid of all these publications and create only one with everything the client is allowed to see? I would then subscribe to it from the group section page controller and work with a single set of data.
Should I simply block any insert/update/remove from client with allow/deny rules and make these using methods only?
Would it be safe/advised to put my methods in both folder so I don't lose the latency compensation feature?
EDIT
Ok, I was freaking out because I had all my collection data on client-side but it was just a bad query in the publish (I was using both field:1 and field:0 projections).
Two questions remain:
If I use methods, I assume I don't have to deny everything in the native driver, I just have to be more restrictive than what method allow, right?
If I put my methods in the both folder, it will be executed both on client and server, so in "client offline" context, even if the client mess with my methods, the server should roll back the changes if the client result is different than his (assuming that the changes couldn't be done using the allow-deny rules)? And I will have latency compensation working even with the methods?
To better control and visualize your subscriptions, you can use msavin:mongol.
Creating one catch-all publication is not a good idea performance-wise (sending all data to all clients will be a pain to everyone involved).
If you use methods and have removed autopublish, then yes everything is denied... Except for updates on the user's own profile. You may want to manually deny that too.
With methods and collection rules you should share the validation code. This way, client and server validate the same way (and should always come up with the same results), so unless your client is screwing up with the console there should be no issue and lag compensation should remain.
If your server method does something the client should not know about, you can also define the method once on the server, and once on the client. Same effect.
I have to implement an architecture where, unfortunately, we are using SharePoint 2013 as, effectively, our principle database. (Not my choice, in case you hadn't picked that up). I have an Asp.Net MVC facade application on the server, handling composition of data from SP and a couple of other data sources, and then a JavaScript SPA as client. An additional wrinkle is that the client needs to be able to work offline, so I need to use IndexedDB to store the data for offline access.
This seems a perfect use-case for breeze.js. My basic architecture is to define a strongly typed model in the MVC facade that will wrap the untyped data I get from SP (in the form object["property"] - using the SP Client Side Object Model). Breeze will handle synchronization between this model and the client, and I will use the export/import functionality to cache data in IndexedDB as required.
So far so good. But... the SOA examples on the breeze site are still under development (and to me, this is fundamentally an SOA architecture, with each SP List a service to be composed). The closest thing I can find is the NoDB sample but this hard-codes metadata on the client. I'd like to establish relationships and validation in the MVC model, and then pass these through to the client, so validation can run off the same declaration in both places.
Is this possible? If so - how? If not does anyone have a workaround or a better idea? I'm already resigned to defining the model in two separate places (the facade and, implicitly, the structure of the SP lists). I would dearly like to avoid implementing it a third time in the client. I'm open to having breeze.js talk directly to the SP REST endpoints, but my understanding from https://stackoverflow.com/a/15364503/1014822 is that the implementation is flawed and does not expose the required metadata.
Resolution: Based on the accepted answer below, I came to the following solution:
1) Generate a service reference from the SP ListData.svc endpoint - thus creating an edmx and proxy classes.
2) Extend ContextProvider in my Repository and override BuildJsonMetadata like so:
protected override string BuildJsonMetadata()
{
XDocument xDoc = XDocument.Load(HttpContext.Current.Server.MapPath("PATH_TO_EDMX"));
String xString = xDoc.ToString();
xString = xString.Replace("DATA_SERVICE_NAMESPACE", "APP_NAMESPACE");
xDoc = XDocument.Parse(xString);
var jsonText = CsdlToJson(xDoc);
return jsonText;
}
3) Modify breeze.js very slightly, editing line 12383:
var schema = metadata.schema || metadata["edmx:Edmx"]["edmx:DataServices"].schema;
(I could presumably also have fixed this in the ContextProvider by choosing a descendant rather than the root node for my xDoc)
4) - Optionally use #Christoff's very useful T4TS.tt template script to generate a d.ts from the service proxy classes so I can have type safety on the data that breeze loads.
So far so good with this setup - I can perform basic CRUD with metadata, backed by SP as a data source.
As of v 1.2.7, We have documented Breeze's metadata schema, and json objects that adhere to this schema that are returned from your webservice will now be honored by Breeze.
--- previous post below
We are in the process of documenting how to expose arbitrary server side metadata over the next week or so, followed soon thereafter by some examples of how to consume an arbitrary web service. There are a few small code changes involved as well.
For the time being, until these docs are complete, the best workaround is to create your metadata on the client and use a jsonResultsAdapter to shape the results of your service call into "entities". The metadata you create on the client will be exactly the same as the metadata that you will eventually be creating on the server and sending down to the client.
Hope this helps.
I'm a new user to D3 and am trying to think about how to best implement a mapping of our configuration items.
What I'm looking for is essentially a treemap (I think) but with inter-related dependencies.
The Data
I'm working with ITIL-style configuration items, so logical services, applications, machines, etc. that make up an IT service that we offer to our customers.
The JSON data I'd be providing is going to come from a WebAPI service that I am defining and so the data can be returned however is necessary.
The Goal
I need to get across:
The name of the configuration item ("Service A", "Server 1", "Database XYZ", etc.)
The configuration item type (represented by either an icon or color -- not too important right now)
Those things with the least dependents at the top
i.e. a service is represented by all the things that compose it -- applications, DBs, etc. and I'd like to have the hierarchy in order from services down.
The relationships between all the elements, which aren't strictly hierarchical.
Multiple services could depend on one application
Multiple applications could depend on multiple databases which could depend on one database server.
If possible, the ability to focus on one branch of the tree from top to bottom by clicking on it (though this can come way later)
Once I get my head around it, I'd like to set up something simple on GitHub and see if I can use D3 to help contribute to the world of IT Service Management.
The Question
Philosophically, is D3 designed to support a visualization of this nature, and what is my best route to accomplish it?
Thanks!
Users will be able to write some documents. Those documents will consists of chapters (one-to-many relation).
Normally I would do this by creating separate views for creating chapter and document.
How to implement web page that allow to edit "composite" view? Where I can edit document details, but also create chapters, without visiting different pages? Also how can I ensure that I pass order of chapter user have arranged (by moving chapters freely up and down)?
(Sorry if that question already have be asked&answered but I do not even know how to search for it :| since I do not know proper keywords beyond "AJAX", so help in naming my requirement would also be welcomed!)
Backend servers applications based on REST principles work nicely with Ajax client-side implementations.
For example, your URLs could be:
/book/1
/book/1/chapters
/book/1/chapter/1
You could set it up so that a POST to /book/1/chapters would add a chapter. A GET on that same URL would return all chapters. A GET on /book/1/chapter/1/ would only return chapter 1. A PUT on /book/1/chapter/1/ would update an existing chapter. This is a "RESTful" architecture:
http://en.wikipedia.org/wiki/Representational_state_transfer
This is an interesting introduction: http://tomayko.com/writings/rest-to-my-wife
This is a big subject, but if you create the right backend server architecture you will find your job a lot easier. Hope this helps answer your question.
Ok Partial solution.
Just google Nested Forms Ruby on Rails. Plenty of examples, all in ajax, all easy.