Предполагая, что вы можете обойтись без закрепления, я бы удалил расширение закрепления из вашей сетки. Это облегчает работу с шаблонами заголовков ... В противном случае вы столкнулись бы с той же проблемой с вашим заголовком (три повторяющихся заголовка).
См. Этот плункер: http://plnkr.co/edit/nvuUKIQczdY2E6KuMEVG?p=preview
Я удалил закрепление, удалил rowTemplate, использовал один headerCellTemplate (заполнитель) для размещения заголовок вашего календаря, и использовали шаблон cellTemplate для размещения логической схемы.
HTML:
Javascript:
var app = angular.module('app', ['ngTouch', 'ui.grid']);
app.controller('MainCtrl', ['$scope', '$http', '$log', function ($scope, $http, $log) {
$scope.gridOptions = {};
$scope.gridOptions.columnDefs = [
{ field:'id', name:'id', width:'25'},
{ field:'name', name:'name', width:'*' },
{ name:'chart', headerCellTemplate:'Include header code here', width:'*', cellTemplate: 'include graph code here' }
];
$http.get('https://cdn.rawgit.com/angular-ui/ui-grid.info/gh-pages/data/500_complex.json')
.then(function(response) {
$scope.gridOptions.data = response.data;
});
}]);
Надеюсь, я правильно истолковал вашу цель и надеюсь, что это поможет:)
9
задан Hosam Aly 30 January 2009 в 20:43
поделиться
Если бы fieldMember является довольно хорошим способом однозначно определить объект, я сказал бы да.
Joshua Bloch размечает, как правильно переопределить, равняется и хэш-код в "Эффективном Java" Глава 3.
Умножение, добавляя, или вещи xor-луга не сделает это более уникальным. Математически, Вы применили бы постоянные функции к единственной переменной, которая не увеличивает число возможных значений переменной.
Такая техника полезна для объединения нескольких хэш-кодов и все еще хранения риска относительно маленьких коллизий; это не имеет никакого переноса вообще на единственном хэш-коде.
Если 'fieldMember' переменная уже реализует функцию 'хэш-кода' затем, можно использовать ее непосредственно от родительского класса. Если 'fieldMember' переменная является пользовательским экземпляром класса, то необходимо реализовать ее правильно собой. Считайте java.lang. Объектная документация API как инструкция для реализации 'хэш-кода'.
Да, это довольно стандартно. И если класс отражает строку базы данных, я просто возвращаю первичный ключ.
Существует только два реальных требования для hashCode
: один, это equals
экземпляры имеют равные хэш-коды, и два, это hashCode
выполнения довольно быстро. Первое требование является самым важным на практике; без него Вы могли поместить что-то в набор, но не найти его там. Второй является просто проблема производительности.
Если алгоритм хэш-кода Вашего поля встречает вышеупомянутое, то его алгоритм также работает на Ваш класс, если Ваш класс equals
также зависит только от того, являются ли те поля equals
.
Ya. Это - хорошая практика программирования. Я обычно использую:
возвратите var ^ 1;
Как кто-то еще упомянул, необходимо последовать совету в Эффективном Java. При переопределении хэш-кода () метод необходимо также переопределять равняние () метод. Кроме того, эти два метода должны быть последовательными.
Упростить хорошую запись равняется () и хэш-код () методы, я использую EqualsBuilder и HashCodeBuilder от Apache палата общин Lang
Вот примеры:
public boolean equals(Object o) {
if (this == o) {
return true;
}
if (o == null || getClass() != o.getClass()) {
return false;
}
User other = (User) o;
return new EqualsBuilder()
.append(this.getUniqueId(), other.getUniqueId())
.isEquals();
}
public int hashCode() {
return new HashCodeBuilder()
.append(this.getUniqueId())
.toHashCode();
}
Обычно, если Вы не используете этот объект в качестве ключа для *HashMap или элемент в *HashSet, хэш-код () не должен быть переопределен.