I was not able to find an answer for the following... please gimme an advice.
I have a form that is built dinamically basing on metadata being obtained from server via ajax request. It gets about 20 values for display data and also about 10 fields for user input. Thus, the presentation view model and post view model are different. Filled fields are posted back via ajax as well.
How do i apply Knockout view models concept correctly?
1. I make a single viewmodel for displaying and posting data. In this case AJAX call will post back a lot of redundant data to server. Option: i can send a new object that will contain only input fields, but it doesnt look OK in KO concept.
2. I make a single viewmodel containing only fields for user input. Read-only fields to display stay out of KO view model and populated using common jQuery methods (so we're out of pure KO style again)
3. Or?
I appreciate your ideas.
Knockout provides the ability to apply MVVM pattern to a client-side (HTML5/Javascript) app. Your JavaScript view model should provide all the data and properties necessary to operate the view or views that it is responsible for, both for user input fields and display-only fields.
Once you post something back to the server, you're leaving the MVVM world and reaching into another layer to perform some operation. As a result, I think it's best to formulate JSON that contains only the data that the server needs to complete the request. On the server side, you may have a C# model with validation attributes or whatever, but, again - you're not trying to adhere to MVVM pattern there.
Hopefully this helps. I'm happy to elaborate if needed.
Related
We have highly complex form in Angular 4 and we want to be able to save form data as an object to be able to send to our DB and also to external APis in json.
Form has tabbed form wizard format and each tab had lot of form controls and each tab itself is very complex.
So we plan to create a data service where at each step, we plan to put data in an object, and keep updating as we nagivate till the end. If user clicks save drafts at any time in form wizard, current state of form data object will go in DB.
Form next, previous work same way, retrieve or updating form data object.
When saving form or submitting form, we will have post http call to backend.
Is there any better approach to achieve this? or we are following right direction. Any examples will be great.
No better approach. You put your complete model in the service. Than create sub-models inside that model that correspond to your individual tabs. In each component, get the model from the service, and keep updating the appropriate model for the tab you are on.
The backend developer has designed the RESTful API in such a way that when going into a section of the site I call one large request for all the data in all the sub sections. These sub sections data can be modified and saved. If that happens I would need to create a new model based on the model from the large request, populate it, and save it to a different service (PUT). This service can only PUT and not GET. I would probably create this model as soon as the user navigated to this section, and display the view based on this new model. Now if i navigated to another sub section, that large request model would be out of date and I'd have to fetch it from the backend again instead of making a smaller request for that section.
I propose to him to just create separate services for each sub section that i can easily fetch and save to (I'm using Backbone). Otherwise I'm creating sub models off a main model and they are dependent on each other and I'd have to write the code to wire them together instead of leveraging the power of the built in methods on the model like save, sync, fetch.
Does this not also create an issue in creating modular components if models are depending on other models?
Has anyone seen it done this way?
I'm in a similar situation. Our API was designed under the philosophy that a single request should give everything needed to render a page. So there's one major API endpoint that returns a main data type, and all nested objects are returned in a partial state. So if I'm requesting "employees", the API won't give a "department id" it will return a partial department object like:
department: { "id": "1", "name": "Department A }
There are great benefits to this approach! Making multiple requests is expensive, and you don't want dozens of API hits for every page load. The problem you'll find is that Backbone was designed for one to one mappings between models and API endpoints. They don't give you anything like a Data Access Layer, if they did both our problems may be solved.
My team generally would make "department" an attribute for the Employee model. This has a big problem. The way that Backbone Models register changedAttributes doesn't play nice with complex objects in attributes, which complicates forms based on data structured this way. It's somewhat frowned upon by Backbone developers too. The general consensus is to store complex objects in a property of the Model class, rather than an attribute.
In any event your parse and toJSON methods will get a lot more complicated than what you'll typically find in examples.
I would recommend you to use BreezeJS, which is built only for data rich application. Check out this link
http://www.codeproject.com/Articles/730450/Creating-Single-Page-Application-using-Hot-Towel-T
I'm currently in the process of trying to define a dynamic form in Play (Scala). What I mean by a "dynamic" form is one which presents different form elements (and POSTs different data) depending on the state of some runtime (specifically database-side) data.
A brief illustrative example: on a to-do list application, how could one create a form which creates a "delete" check box next to each of the list elements? I realize this could be done with GET links or with AJAX/javascript, but I want this to be a standard POST form with a "submit" button.
I'm aware of the repeated mapping form functionality, but is it possible to define an even more dynamically generated form, where the structure is less strict than just single+repeated elements?
Thanks for any suggestions you might have. I realize this might just be more than POST is cut out for.
The closest thing that I have to an answer for this is that POST and any sane web framework supports "array" inputs. Hence, if you can get your data into any regularized format, you can serialize/deserialize via that. You may be able to support semiexotic data patterns by using this method as well.
I keep on finding myself wanting to add fields to CRM forms that don't actually represent physical fields on the entity. I want these fields to be sent in the Update message, for the benefit of my Plugins...
For example, imagine something like the out-of-the-box contact/address functionality. The main contact address is exposed as a set of fields on the Contact form. However, in actual fact there is some magic going on behind the scenes that causes an Address record to be created for the Contact containing the address details. I don't actually want to reproduce this, but it's a fair example...
Now, I know how to write a plugin that takes the address fields entered in the Create/Update message, and actually writes them into an Address object instead. That is simple enough. It seems the hard part is convincing CRM to display fields on the form for the user to enter the address data.
The only way I can see to do this is to create "fake" fields in the Contact-equivilent form, so that the form editor allows me to add the fields to the dialog. Then I have to filter these attributes out in a plugin, so the fake fields don't actually get written to the DB.
This would work, but involves filling the DB schema with fake columns that will (or should) never have any data in them. This makes future cusomisation of the system more confusing, as there are decoy fields called "DON'T USE - Address1" knocking around in all the GUIs. The problem gets worse when I need a fake Lookup field - this involves creating a fake relationship.
So: Is there a way to achieve the same thing without dumping fake garbage in the database schema?
Is there, perhaps, some way to create a form field for an arbitary attribute in Javascript on the form, such that the Attributes will be included in an Update message?
Sure, I realise I could IFrame or Silverlight something up to cater for this, but I'd rather use the genuine CRM form fields, and handle the data in the Update/Create message plugin hook.
Unfortunately, you have already mentioned the two options that I can think of: fake fields or custom IFrames.
I know it feels "dirty" but I actually haven't had much trouble doing the fake fields thing. Standardized naming conventions are your friend. I prefer fake fields over IFrames because users can still query and filter them in Advanced Find, reports, views, etc.
Just make sure they are readonly and make sure your plugins don't swallow exceptions - you want exceptions to bubble up and cancel the transaction instead of the possibility of the main record getting updated without the children.
I'm developing an ASP.NET MVC application where the content for any page can be pulled from the database, if it exists, and displayed on the page.
This is to make it possible for non-technical persons to edit the content without having to go into the source code (e.g. views) and change things.
The way I'm doing this is, each controller derives from a base controller. The base controller overloads 'OnActionExecuted' and takes this opportunity to pull any content assigned to the current Action/Controller.
If the action returns a ViewModel that derives from 'ContentViewModel', it populates the 'Text' property of the ViewModel with the text from the database.
And then the text gets rendered by the View.
Can you see any weakness to this design?
Would it be better if, rather than having a base controller, I had HtmlHelper extensions for pulling content, which I call from the View?
One reason I'm asking this is, having my own base controller seems to interfere with calling 'Html.RenderAction', which seems to expect the specified controller to directly inherit from 'System.Web.Mvc.Controller'.
ActionFilters should not be used to pull the content.
Controllers should not be used to pull the content but only to dispatch the incoming requests by applying simple logic.
HTML helpers should not be used to pull any content. They are meant to render UI elements prefilled with the supplied data.
application where the content for any page can be pulled from the database
That's basically how most applications operate.
This is to make it possible for non-technical persons to edit the content without having to go into the source code (e.g. views) and change things.
For non-technical persons to edit content there should be an appropriate UI. Independently of the project underlying technology, non-technical personal is never supposed to edit the code.
I suggest you don't make anything weird but keep things clear. Implement your business layer that will supply the data to models which the view will render. Create a UI for other people to edit the content.