I've an web application written using Backbonejs which consists of two modes
1. Read
2. Edit
I have a view and a corresponding model associated with it.
Following is the behaviour, I'm trying to achieve
Not all properties of model, I'm going to show in the read mode
All properties of model will be shown in edit mode
The view is being given some additional responsibility in edit mode which is being achieved using mixin
I do not want to bring extra information in read mode
I do not want my server side logic to know whether the application is in read or edit mode
Do someone thinks that creating two seperate models for a view depending upon mode and creating altogether different service will solve my issue ?
Since it is the same model's information you are trying to work with, you will need a Read View and an Edit View, but can use the same model and be selective about the attributes you want to deal with in either of these views
Related
When I try to create some entities I don't see the option to input fields. I just see the SaveEntity button.
However I can view all the existing entities.
What is very strange is - there is another entity called VideoEntity for which the create did not work yesterday but works today.
Can somebody help me with this seemingly unpredictable tool ?
Regards,
Sathya
i think the console knows what properties each entity has based on existing data, rather then your models. and the data is only updated periodically. when did you upload your app? maybe waiting a few hours will give the console time to update.
alternatively, you could use the remote api to add your entities, or write a small snippet and upload such as ...
VideoStatsEntity(app='home', ip='116.89.52.67', params='tag=20130210').put()
Writing a simple interface to the data-store to allow you to edit/create models is probably the best thing to do in this case. You know what they contain so you can adjust your interface accordingly, rather then waiting for the admin interface to "catch up" as Gwyn notes.
I believe that there are some property types that are impossible to add via the admin interface that you are using so you'll probably get to the point sooner rather then later of creating a custom interface.
The admin datastore view is good for quickly checking out the contents of the datastore, but ever tried paging through 100's of entries? Not fun.
I have a tree of models and I'd like to have them load from one big JSON request up front and then be able to change them one at a time without saving the whole tree or reloading the whole tree and without making two versions of each model.
The problem I've encountered is if each of the submodels has a keySource they won't upfront load, but without a keySource you can't do an individual load or save.
My content in the upfront load is the entire object tree fully connected (no id lists) because I didn't see a way around this. Is that the problem? Or is what I'm trying to do just not possible without two versions of the models that are somehow connected?
It is possible to do selective saving if you override the save method of Backbone.Model. I wrote an article on this topic. Your choice if you want to create little sub-models that represent parts of your model. When those are changed, you can get their changedAttributes hash and pass it to the save of the main model. With the method I discuss in the article it is entirely possible to post only parts of your model during a save.
Have you considered using a collection for this? You could override the parse method of collection to create your models. Just a thought.
I want to build a MDI (multiple document interface) application that displays multiple instances of one model (i.e. users) at the same time in separate panes (here: within a tabpanel).
My normal approach would be to create a controller for each instance that contains all necessary views and stores. But as I have understood the architecture this is not possible. I can have multiple views and stores but only one controller. View creation can be done automatically by haveing a master view that contains all of the other views. But with stores it is not that easy if I do not want to use nested models/stores. So I have to create all stores by hand.
Is there really no possibility to manage all this by multi-instantiate the related controller? Or is there another elegant way to solve this problem?
I've seen the diagrams, but I want a description of how it all works -- for example -- cakephp uses the controller file and the view file. What happens? Is there anything out there? It would make using cakephp's mvc easier.
most simple request would look something like the following:
when you request a url, the router figures out what is needed and then uses the Dispatcher to open up the controller and run the corresponding method.
As the controller is fired up it includes and builds up the model that corresponds to that controller.
your method will then run and do what ever it needs to do.
When the controller is done calling all the code you have included the view class is executed which starts the rendering. It will include and render the corresponding view file and then the layout that has been set in the code.
all along the way there are a number of callbacks that are triggered in the various parts of the code, like controller::beforeFilter model::afterFind etc. Best to have a look a the api and book for more detailed information or ask a more specific question about that.
If you're at all familiar with Object Oriented code and php functions, you can start to read the CakePHP core methods. They will fill in a lot of blanks in terms of understanding the internal mechanics and relationships of Models Controllers and Views.
I'm creating a module and I was able to add a user control as a view type and everything worked. I want to add a second control, also as a view type, but that's where trouble begins.
If I just add the new control to the module definition, it displays only that control and not both. If I remove it, the original control displays fine. Going back into the module definitions, I went to the module controls and assigned values to the respective Key properties. When I save, my module disappears from the page it was displayed on. If I try to add it again, I get "Object reference not set to an instance of an object."
It was through trial and error I discovered if I remove the key, I can re-add the module it works again (at least as described above).
Essentially I want multiple views for my module where individual views can be displayed on different pages (much like the Blog module). I'm not creating a package for distribution so I'm almost to the point of just creating a separate module, but where's the learning experience in that?
I've searched for a tutorial on creating a module with multiple views with no luck. Can anyone provide some insight?
I got round this issue by using the modulesettings to choose which display I wanted for that instance, in my case I used the setting to determine which front end was visable and which was not aswell as the backend code.
Another option is to have one view ascx which is a placeholder and inject either ascx view you want based on a modulesetting.
I have used both these methods before and both work well
In DotNetNuke there can only be one 'View' so if you want to make something that displays different views depending on the situation you have to create a Dispatch view. So depending on your module setting like you have, or a URL parameter, cookie, session, something in the primary View gets another user control to display what is needed.
This post talks about it a bit Dispatch View
Sounds like you found a solution that works for you.
Out of the box DotNeNuke also supports using multiple views, however as soon as you switch to a different view the module enters "Isolation Mode", where it becomes the only module visible on the page.
If this behavior would work for you, then you can add multiple controls, the FIRST control you add without a key, the secondary controls you add with a specific key. You can then use NavigateUrl or EditUrl to construct the link to the specific controls.
From an "edit" perspective, the use of this pattern ensures that your users have a consistent environment with only your module. From a View perspective the usage of other patterns is more commonly a "better" choice.