I need the extjs 4 behaviour for new model objects to have a null id rather than a "Model-1" generated value in extjs 5+
Therefore I have created a id generator
Ext.define('Example.data.identifier.Custom', {
extend : 'Ext.data.identifier.Generator',
alias : 'data.identifier.custom',
generate : function() {
return null;
}
});
But now my grid grouping features behave strange. I think it has to do with the id assigned to the additional grouping row to be also null.
Is there a way around?
The ExtJS 4 behaviour of null ids does not work in ExtJS 5+ - you need to have ids, especially for objects in stores.
So accept the fact that all of your Model instances will need to have id values. You can determine if they were created locally or via retrieving from the backend using the phantom property. You can use a custom proxy to strip the id property when saving if you need to. You can use different endpoints with the AJAX proxy, or different HTTP Request Methods with the REST Proxy, so your backend can know if you are making a new record or updating an existing one.
But you can't get away with having duplicate IDs, including null values. Accept that, and move on.
Related
I have used this to chain dynamic data drop downs in an Orbeon application using the following services:
1. /xforms-sandbox/service/zip-states
2. /xforms-sandbox/service/zip-cities?state-abbreviation={../state}
3. /xforms-sandbox/service/zip-zips?state-abbreviation={../state}&city={../city}
I have few questions:
I also want to create the same, so can you please point me the code where this services are present. How I should write the service in this case?
{../state} - How it retrieve the state value when it changed?
What is the use of state-abbreviation?
This specific test service is implemented in XPL and XSL, in zip-states.xpl. But it really just is a service that gets called with an HTTP GET by Orbeon Forms, and returns XML. BTW, you can easily test it from your browser, and it could be implemented with any technology.
Whenever the value of the control named state changes, {../state} will return a different value, so the URL for the service will change, so the Dynamic dropdown will load again that URL to retrieve potentially new data.
In this particular example, we want the "abbreviation" to be stored in the data (e.g. "CA"), and the full name (e.g. "California") to be shown in the UI. Again, in this particular examples, values come from states.xml.
I'm developing a SPA webapplication with DurandalJS, but I don't understand something.
Let's say I have page 1 and 2. On page 1 there is a modal that creates a entity in the database with BreezeJS and gives back a key (that was generated in the database).
I want to pass this fetched key and then go to my second page, page 2. I know how I can do this when I put it in the url
http://localhost:60312/#/page2?orderid=2&repairorder=2
But this is not the way for Durandal, or is it? A user can enter a number of his own with al consequences!
How can I solve this?
I would like to add something to the very good #Joseph Gabriel answer. In durandal you can do this:
router.map( url: 'page2/:orderid/:repairorder',
name: 'Page2',
moduleId: 'viewModels/page2');
http://localhost:60312/#/page/2/2
But also, you can do this:
router.map( url: 'page2',
name: 'Page2',
moduleId: 'viewModels/page2');
http://localhost:60312/#/page2?orderid=2&repairorder=2
You don't nedd to specify all the parameters that you are pasing. Yo can get this parameters from the input of the active method.
var activate = function(context) {
console.log(context.orderid);
console.log(context.repairorder);
}
Sometimes the second solution can be more appropriated if you want that the user can store the url to repeat a query only copping that in the browser.
As far as I know, the only seamless way to pass parameters between view models in a Durandal app is to use the normal hash-based url parameters.
In you example, you can define a router that takes a orderId and repairOrder parameters, then your url would look something like this: http://localhost:60312/#/page/2/2
This is best option, if your data isn't too sensitive. Leave the navigation parameters in the open, and handle the values with care in the second view model. In other words, design your view model so that it can properly handle any values - even if a user directly modifies a parameter value, your view model should be able to handle it correctly.
It can be advantageous to be able to set url parameters directly, but you do have to be careful to ensure the integrity of the values before consuming them.
However, if you need to hide the parameters, you do have some different options:
Encryption: Use an encryption library like tea.js, and encrypt the value before adding it as a parameter value for navigation. Then, of course, decrypt it on the second page before using it. This allows Durandal's router navigation to work normally, while preventing users from supply their own values.
If you really need to prevent users from entering their own values, and you can bear the overhead of a few extra KB's, this is a good approach as long as you only need to pass a few parameters.
Shared data model: Use a singleton model which is shared between the two view models. This model can be manually required() as needed, and essentially serves as a repository for the application state that is shared between one or more view models.
This works fine, but it's kind of like having a big global variable - it can get messy if it's overused.
Modify VM directly: (Only for singleton view models)
Manually require() the second view model and set its properties before navigating to it.
I'm developing my first Spring 3 webapp. In Spring 2, we used to have formBackingObject load data from the database, then let Spring binding update some of the fields, and then onSubmit would persist those changes.
In Spring 3 it seems I have two options:
Let the user edit 100% of the persistent object. This would mean that the object's ID would need to be a hidden field
Create a form object which holds the editable data, and then map that onto the persistent object on submit
The first option is not truly an option, we cannot let the user edit all fields, and we'd rather not present data in hidden fields where anyone capable of pressing F12 can alter the values.
The second option seems like a decent design approach. However, it appears that it requires to essentially clone every editable, persistent class.
#Entity
public class Company {
private String uuid; // not editable!
.. 30 other properties, 2 are not editable
}
public class CompanyForm {
.. 28 of above properties
}
and then some mapping mechanism with lots of
public void map(CompanyForm cf, Company c) {
cf.setName(c.getName());
.. 27 other set(get())
}
I'm praying this is not the "as designed" approach of Spring's MVC binding. However, all tutorial I've found so far are terribly trivial and implement option 1 from above. Does anyone have some suggestions for implementing option 2?
Thanks, Simon
DataBinder API
Note that there are potential security implications in failing to set an array of allowed fields. In the case of HTTP form POST data for example, malicious clients can attempt to subvert an application by supplying values for fields or properties that do not exist on the form. In some cases this could lead to illegal data being set on command objects or their nested objects. For this reason, it is highly recommended to specify the allowedFields property on the DataBinder.
You can use it together with option 1
A pragmatic way would be to just ignore the non editable fields on the update statement.
I have actually circumvented this in the past by using a #ModelAttribute annotation and detecting the PK on the request, if you do it this way Spring will use the object that is returned from #ModelAttribute and automatically copy the submitted object to it.
It's kind of a hack and not obvious to someone who comes in to maintain the code though.
Suppose that on single page there are two grids which has same column but different records to display.
There could be two solutions to it:
Use same Model and Store and filter on store before rendering the grid.
Potential Problem in this solution: Since the underlying store is same, when the second grid will be
Rendered the filter on first grid will get wiped off.
Use different Store definition and Model Definition (Keeping proxy and fields same as other store/model definition, but just changing the name):
Problems: I tried this on Pandora application and it started giving strange issue such that the second grid did not display any records.
Which approach is better and how to resolve the corresponding issues.
-Thanks
We faced exactly same problem in our project. I ended up using the following approach:
you define one model and one store class
load store from the server for the first grid
clone store object with all records (you might want to google for how exactly to do this)
at this moment you need to decide whether you need just a local copy or copy that tied to the same data source on the server - both can be implemented based on what you need
I can post some sample code for cloning if you need it.
UPDATE
Here is code sample to clone store object:
cloneStore: function(store, storeClass) {
var new_st = Ext.create(storeClass),
recs = [],
filter;
store.each(function(r) {
recs.push(r.copy)}
);
new_st.add(recs);
return new_st;
},
The approach I took and recommend is not to reference the same instance of the store but create a new instance of your store for each grid:
store: Ext.create('MyStore',{...});
I have 3 domains :
- EligibilityInclusion
- EligibilityExclusion
- EligibilitySummary
I build also eligibility.gsp (mix use of 3 templates : _inclusion, _exclusion, _summary ; and I'm also using JQueryUI tab to render each domain in one tab).
Everything fine for viewing, but now I would like to use only one controller to create, edit, list and show.
How can I handle 3 domains via only one controller?
(for example, I would like to use EligibilityController to handle my 3 domains)
What is the best usage:
- binding multiple objets?
- use command objects?
Unfortunately command objects don't help with the input model for a view, they are specifically designed to aide the output model for the binding and validation of request parameters. However you can roll your own View Model based on a command object if you are prepared to delve into some meta programming to to achieve the data binding for the creation of the view model.
Here's a basic approach. The following code constructs the Command Object which you can then pass as the model to the view in the controller:
class ItemCommand {
// attribute declarations ...
public void bindData(def domainInstance){
domainInstance.properties.keySet().each { prop ->
if(prop == "class"){
// not needed
} else if(prop == "metaClass") {
// not needed
} else if(this.properties.containsKey(prop)){
this."${prop}" = domainInstance."${prop}"
}
}
}
This will allow you to bind the data from different domain objects by calling bindData for each of the domain objects.
This is the essence of the solution I use. You will need to store the ids of the different domain objects (and the version attribute) as hidden fields if you intend to do updates to the domain objects.
You can't just submit multiple objects, if some of them have same field names, right?
I'd try to join the 3 objects into single Command with 3 fields, like: inclusionInstance1, inclusingInstance2, summaryInstance1, and name fields in gsp-s respectively, like name='command.inclusionInstance1.name'. Assigning command.properties = params should work when submitting the form.