Опыт с помощью extjs с чашами Грааля?
hash_map использует хеш-таблицу. Это "постоянное" время в теории. В большинстве реализаций используется хеш-таблица "столкновения". На самом деле происходит следующее:
- Он создает большую таблицу
- У вас есть «хэш» -функция для вашего объекта, которая генерирует вам случайное место в таблице (случайный вид, но хеш-функция всегда будет возвращать одно и то же значение для вашего объекта), и обычно это мод фактического 32-битного (или 64-битного) хеш-значения с размером таблицы.
- Таблица смотрит, есть ли свободное место. Если это так, он помещает элемент в таблицу. Если нет, он проверяет, есть ли элемент, который вы пытаетесь вставить. Если это так, то это дубликат, поэтому без вставки. Если нет, то это называется «столкновением» и использует некоторую формулу для поиска другой ячейки, и продолжается до тех пор, пока не найдет дубликат или пустую ячейку.
- Когда таблица заполняется слишком сильно, она меняет размер. Эффективная (по времени) реализация будет хранить все исходные значения хеш-функции вместе с элементами, поэтому при этом не нужно будет пересчитывать хеш-значения. Кроме того, сравнение хэшей обычно быстрее, чем сравнение элементов, поэтому он может делать это во время поиска, чтобы устранить большинство коллизий в качестве предварительного шага.
- Если вы никогда ничего не удаляете, это просто. Однако удаление элементов добавляет дополнительную сложность. Ячейка, в которой был элемент, который был удален, находится в состоянии, отличном от того, который был все время пустым, поскольку у вас могут быть коллизии, и если вы просто очистите его, эти элементы не будут найдены. Так что обычно есть какая-то «отметка». Конечно, теперь, когда мы хотим повторно использовать ячейку, нам все равно придется откатываться вниз в случае дублирования нижнего дауна (в этом случае мы не можем вставить в эту ячейку), затем не забывать повторно использовать удаленную ячейку.
- Обычным ограничением является то, что ваши объекты должны быть реализованы для проверки на равенство, но Dinkumware (или это был SGI) реализовал их с оператором < который может быть медленнее, но имеет преимущество в том, что разделяет ваши элементы и тип связанного контейнера, в котором они могут храниться, хотя вам все еще нужна хеш-функция для хранения в хэше.
Теория состоит в том, что если у вас достаточно большая таблица, операции выполняются с постоянным временем, то есть оно не зависит от количества имеющихся у вас элементов. На практике, конечно, чем больше у вас элементов, тем больше столкновений.
std :: map использует двоичное дерево. Нет необходимости определять хеш-функцию для объекта, только строго упорядоченное сравнение. При вставке он перемещается вниз по дереву, чтобы найти точку вставки (и есть ли какие-либо дубликаты) и добавляет узел, и, возможно, потребуется перебалансировать дерево, чтобы глубина листьев никогда не превышала 1. Время перебалансировки также зависит от глубины дерева, поэтому все эти операции - O (log N), где N - количество элементов.
Преимущества хеширования - сложность. Преимущества дерева:
- Полностью масштабируемый. Он использует только то, что ему нужно, не нужно для огромного стола или для уменьшения размера стола, хотя для хэша может потребоваться меньше «багажа» на элемент, чем для дерева.
- Нет необходимости сначала хэшировать, что для хорошей функции может занять больше времени, чем сравнение, если бы набор данных не был большим.
Еще одна проблема с std::map состоит в том, что он использует одну строго упорядоченную функцию сравнения, в то время как функция «сравнения», которая возвращает -1, 0 или 1, будет намного более эффективной, особенно с наиболее часто встречающейся функцией. используемый тип ключа std :: string, в котором уже реализована эта функция (это char_traits::compare). (Эта неэффективность основана на предпосылке, что для проверки того, что x==y, вы проверяете x<y и y<x, так что вы делаете два сравнения. Вы сделали бы это только один раз за поиск).
2 ответа
Я часто использую комбинацию Grails + ExtJS, и ее довольно легко реализовать. Вывод JSON для сеток можно легко получить, выполнив что-то вроде этого в ваших контроллерах:
def list = {
def books = Book.list(params)
render( [ items: books, totalCount: Book.count() ] as JSON )
}
это создаст "Ext-совместимый" JSON, например:
{"items":[{"class":"Book","id":1,"title:"The Definitive Guide to Grails","author":"Graeme Rocher",...
это пример того, как вы должны инициализировать JsonStore:
var store = new Ext.data.JsonStore({
url: '${createLink( action: 'list' )}',
root: 'items',
totalProperty: 'totalCount',
fields: [ 'id','title','author','isdn', 'dateCreated' ],
paramNames: { start : "offset", limit :"max", sort : "sort", dir : "order" }
});
При работе со значениями даты рекомендуется использовать формат даты Javascript для конвертера JSON (т.е. значения даты будут отображаться как новая дата (123123123) вместо формата по умолчанию «2009- 04-16T00: 00: 00Z "), поэтому вам не нужно беспокоиться о формате даты или часовом поясе. Вы можете сделать это, настроив его в вашем grails-app / conf / Config.groovy:
grails.converters.json.date = 'javascript'
Я также реализовал функциональность на стороне сервера для плагина фильтра сетки, различные комбинации реализаций поля со списком (с удаленным автозаполнением), деревьев, форм и т. д. Если вы хотите увидеть больше примеров кода для этого, дайте мне знать.
ExtJS 3.0 (в настоящее время RC) еще лучше интегрируется с Grails, поскольку хранилища данных предоставляют возможность отправлять данные обратно на серверную часть для сохранения. Подход Ext.Direct также предоставляет новые возможности: -)
См. Этот
http://ffzhuang.blogspot.com/2009/03/build-j2ee-application-with-extjs.html
Это хороший пример и весь сайт www.feyasoft.com работает под extjs + grails. А вы можете попробовать наш календарь - с открытым исходным кодом.