Grid-ы

[Closer]

Привет All,
Поискал в обсуждениях темы по ключевым словам "grid" и "грид".
Странно, но даже упомнинаний о гридах не нашел. Гугл и поиск по
группам дал больше результатов:
ajax-grid - с rubyforge.org вроде как мертвый (последние изменения за
2006)
synthesis - похоже самопальный грид
Ext Grid - грид на JavaScript. ИМХО через чура навороченный.
Flexigrid - вроде как рабочий

И больше ничего не нашёл... И возник у меня вопрос кто какие
компоненты использует для создания гридов и использует ли вобще?

Заранее спасибо

[Denix]

Можешь попробовать, вот этот гринд, на основе jquery: http://webplicity.net/flexigrid/

Я лично extjs юзаю.

[Closer]

Я как раз сейчас разбираюсь с flexigrid, только вот как я понял
документации по его API нет...
Если ничего с ним не получится попробую extjs

А ещё есть grid-ы?

[Michael Bykov]

Я вот так ничего готового и не нашел, и стал использовать
activescaffold, хотя мне нужна только отрисовка табличек.

1. Табличка должна настраиваться не в модели и не в контроллере,
2. Сортируемые колонки
3. Суммы внизу
4. Поиск (м.б. по мере набора)

Кажется все

М.

29 июня 2008 г. 0:11 пользователь Closer <close...@gmail.com> написал:

[Dmitry Shaposhnik]

Не нашли чего-нибудь стоящего? А то как
раз подошел к тому же вопросу с такими
же требованиями (минус сумма и плюс
листалка - записей может быть много).

[Closer]

Нет, так и не нашел. Посмотрел на Ext Grid, но как-то стрёмно. Я так
понял он всю свою разметку генерирует на JS, а к такому подходу у меня
доверия нет.
Flexigrid тоже как-то мне не понравился. Документации по нему нет
совсем.
А activescaffold ещё не пробовал.

Вобщем я так понял что к гридам есть пока только такой подход: если и
искать гриды, то только не(!) под Rails, а найдя интегрировать их в
Rails.

[Dmitry Shaposhnik]

Я пока накопал вот это:
http://www.smashingmagazine.com/2007/05/30/tables-and-data-grids-with-ajax-dhtml-javascript/
и в силу того что мне нужно было
реализовать сделал как тут:
http://dev.nozav.org/rails_ajax_table.html

Также наткнулся на это:
http://unspace.ca/datagrid/update

Попутно в голову пришла мысль - а ведь у R
edmine (http://www.redmine.org/) таблица с
сортировкой и фильтрами уже
реализована. Без возможности правки,
но все же.

[Yuri Leikind]

Привет,

Я собираюсь в скором времени опубликовать плагинчик, который  может следующее (copy-paste из документации):

WiceGrid substitutes your usual view table with a table with

*paging

*sortable columns

*filtering by multiple columns

 All working nicely together. Filters are added automatically according to the type of the column. More than one such grid can appear on a page.

Или вот пример

Controller:

        @accounts_grid = initialize_grid(ApplicationAccount,

          :conditions => some_conditions,

          :order => 'username',  # это только первоначальная сортировка при первом рендеринге

          :include => [:user_group, {:identity => :person}])   #  :joins => '' is accepted as well

View:

  <%= grid(@accounts_grid, :table_html_opts => {:class => 'grid_style', :id => 'accounts_grid'}, :header_tr_html_opts => {:class => 'grid_headers'}) do |g|

    g.column :column_label => 'Username', :attribute_name => 'username' do |account|  

      account.username

    end

    g.column :column_label => 'application_account.field.identity_id'._, :attribute_name => 'firstname', :model_class =>  Person do |account|

      link_to(account.identity.name, identity_path(account.identity))

    end

    g.column do |account|

      link_to('Edit', edit_account_path(account))

    end

end

Блоки g.column{} вызываются для каждого ActiveRecord объекта из найденных и возвращаемое значение будет содержимым для cell  соответствующей колонки.

 Получится табличка с pagination, сортировкой по колонкам username и people.firstname,     и автоматически добавленными фильтрами для первых двух колонок, в этом случае это будут text field. Поддерживаются также фильтры для boolean (dropdown yes/no), date, datetime (эти пока выглядят ущербно), fixnum & integer (два text fields для границ 'от' и 'до') , и custom dropdown lists.

Возможна фильтрация по более чем одной колонке. Любое количество гридов на странице.

 Штука имеет свои ограничения, но мы внутри нашей компании ее уже вовсю используем везде вместо простых html таблиц в 95 случаев из 100,  экономит много времени.

Правда, до этого использовалось только для MySQL, и требует will_paginate не старее 2.2.1.

Мне остается дописать документацию.

Похоже  ли это на то, что нужно?

__

Юрий Лейкинд

2008/6/27 Closer <close...@gmail.com>:

--
Best regards,
Yuri Leikind

[Closer]

[skipped]

> Мне остается дописать документацию.
>
> Похоже  ли это на то, что нужно?

Да, ИМХО это похоже на Grid которым можно будет довольно удобно
пользоваться :)

Сортировка, paging и фильрация осуществляется через AJAX?
И есть ли возможность кастомизации формируемого грида посредством CSS?
Я заметил что есть какой то ключ header_tr_html_opts...

Заранее спасибо :)

[Michael Bykov]

Юра, а обязательно запрос должен быть в форме :conditions=>, :include
и прочее в том же духе? А если я хочу построить таблицу по
произвольному запросу, типа

@grid = Model.method

так можно?

М.

10 июля 2008 г. 22:06 пользователь Yuri Leikind
<yuri.l...@gmail.com> написал:

[Yuri Leikind]

2008/7/10 Closer <close...@gmail.com>:

[skipped]

> Мне остается дописать документацию.
>
> Похоже  ли это на то, что нужно?

Да, ИМХО это похоже на Grid которым можно будет довольно удобно
пользоваться :)

Сортировка, paging и фильрация осуществляется через AJAX?

Нет, это good old plain HTTP, впрочем горстка вспомогательного js  присутствует.

 

И есть ли возможность кастомизации формируемого грида посредством CSS?
Я заметил что есть какой то ключ header_tr_html_opts...

Да, вполне все кастомизируется, стили, иконки, через опции, плюс есть стили которые остается только

переопределить, например, стиль для оттортированной колонки. Будет в документации.

 

Заранее спасибо :)

Будет самодисциплина, закончу на выходных :)

[Yuri Leikind]

2008/7/10 Michael Bykov <m.b...@gmail.com>:

Юра, а обязательно запрос должен быть в форме :conditions=>, :include
и прочее в том же духе? А если я хочу построить таблицу по
произвольному запросу, типа

@grid = Model.method

так можно?

В смысле вместо

@grid = initialize_grid(MyModel, ...)

вот так:

@grid = MyModel.grid( ...)

Я правильно понял?

[Michael Bykov]

Нет, я нахожу произвольное подмножество некоторыи методом, вот так:
Person.half. А не использую опции find-a, чтобы создать выборку.

То есть @grid = initialize_grid(Person.half)

M.

11 июля 2008 г. 2:05 пользователь Yuri Leikind <yuri.l...@gmail.com> написал:

[Yuri Leikind]

2008/7/11 Michael Bykov <m.b...@gmail.com>:

Нет, я нахожу произвольное подмножество некоторыи методом, вот так:
Person.half. А не использую опции find-a, чтобы создать выборку.

То есть @grid = initialize_grid(Person.half)

Нет, сорри, не вижу в этом смысла.

[Closer]

Смысл в разделени обязанностей. Модель каким-то чудесным образом
получает данные (берёт их из БД, берёт из нескольких БД, берёт из кеша
и т.п.), а грид в представлении просто отображает их. Поэтому логично
поместить всю работу с БД в модель (где она и должна быть) или в
крайнем случае в контроллер (как это сделано у тебя).

P.S.
Немножко в сторону: ИМХО Вобще завязываться на ActiveRecord не самая
лучшая идея т.к. данные для грида могут прийти из разных источников
(примеры я привёл выше). Поэтому должен быть какой-то интерфейс через
который грид должен взаимодействовать с моделью.


On 11 июл, 19:04, "Yuri Leikind" <yuri.leik...@gmail.com> wrote:
> 2008/7/11 Michael Bykov <m.by...@gmail.com>:

[Michael Bykov]

Смысла полно. Например, мы используем has_finder.

Но главное - если есть теоретическая возможность построения запроса к
бд, который не выражается через параметры к find, то по закону
бутерброда, первый же пользователь, которому нужен ваш плагинчик
(например, я) - наткнется (наткнулся) на этот случай.

И я вообще не понимаю, зачем вы пошли этим путем. AS тоже так делает.
Загадка. А нужно - есть массив данных - нужно построить грид, всё. А
как я делаю запрос и к чему - не входит в компетенцию пожарной охраны,
как говорил Остап.

M.

11 июля 2008 г. 19:04 пользователь Yuri Leikind
<yuri.l...@gmail.com> написал:
>
>

[Yuri Leikind]

2008/7/11 Closer <close...@gmail.com>:

Смысл в разделени обязанностей. Модель каким-то чудесным образом
получает данные (берёт их из БД, берёт из нескольких БД, берёт из кеша
и т.п.), а грид в представлении просто отображает их. Поэтому логично
поместить всю работу с БД в модель (где она и должна быть)

Супер. Начинай писать.

 

или в
крайнем случае в контроллер (как это сделано у тебя).

Откуда у тебя мой код, откуда ты знаешь, что там у меня где?

 

[Yuri Leikind]

2008/7/11 Michael Bykov <m.b...@gmail.com>:

Смысла полно. Например, мы используем has_finder.

Но главное - если есть теоретическая возможность построения запроса к
бд, который не выражается через параметры к find, то по закону
бутерброда, первый же пользователь, которому нужен ваш плагинчик
(например, я) - наткнется (наткнулся) на этот случай.

И я вообще не понимаю, зачем вы пошли этим путем. AS тоже так делает.
Загадка. А нужно - есть массив данных - нужно построить грид, всё. А
как я делаю запрос и к чему - не входит в компетенцию пожарной охраны,
как говорил Остап.

Есть огромная таблица. Нужно отрисовать во view N записей начиная с M, из

подмножества всех записей, удовлетворяющих ряду условий (фильтры), и 

отсортированных по одному из полей. При этом это не какой-то статический код

в контроллере или модели, все условия задаются пользователем динамически, 

обрабатываются в коде и результатом является один эффективный sql запрос.

Вижу, очень хочется на вход подать список готовых объектов? Я так понимаю,

никто тут не собирается тащить в память ВСЕ записи и инстанциировать для

них AR объекты, чтобы грид осортировал и отделил ненужно? Значит для того, чтобы

создать этот список, придется повторить все  те движения, который уже делает

 плагин - обработать параметры запроса, тем или другим образом (has_finder

или что-то другое, неважно, все равно конечный результат - sql запрос), так,

чтобы результирующие limit, offset и where были верными. Очень хочется

это делать вручную? На здоровье. Только для меня это шаг назад

и ненужное теоритезирование.

[Michael Bykov]

я имею на практике случай, увы, когда после запроса к базе мне нужно
преобразовать, суммировать и классифицировать результаты. Наверное,
да, это можно сделать эффективно в развитой базе данных. Но мы-то,
смертные, работаем с MySQL или c SQLite.

Я себе голову сломал, как это отобразить в AS. Догадался, но пришлось
заменить их обращение к find и просто подсунуть ему результат.
Получилось, но мороки было много.

Так что где-то вы правы, признаю - на больших таблицах, где нужна
эффективность. А у меня маленькие таблицы с довольно хитрыми (хотя
ничего особенного) связями.

Так что если сможете добавить такую функциональность, было бы здорово.
Если нет, все равно вам лично респект, честь и хвала. Код будет открыт
под GPL, я так понимаю? Тогда сообществу и карты в руки. А если не
будет открыт, нечего и обсуждать.

М.

11 июля 2008 г. 23:26 пользователь Yuri Leikind
<yuri.l...@gmail.com> написал:
>
>

[pronix]

А что такое грид объясните пожалуйста

[Michael Bykov]

табличка

12 июля 2008 г. 0:59 пользователь pronix <pronix....@gmail.com> написал:

[Yuri Leikind]

Ладушки, на этом предлагаю обсуждения на время закончить.

2008/7/11 Michael Bykov <m.b...@gmail.com>: