Видимо так.
Эта статья рассматривает довольно узкие условия, когда нужно просто заменить значения в некоторых ячейках.
Как идея (не проработанная), можно сделать достаточное кол-во пустых строк и просто скрывать не используемые строки, оставляя только те, которые потребовались.
Тогда нумерацию можно не менять.
То есть тогда задача сводится снова к этой узкой области «только редактирование».
Не выкладывал.
Посчитал решение сильно тривиальным и слишком простым для того, чтобы куда-то его выкладывать.
Сейчас я практически не пишу под django, переключился на flask.
Проект, в который входит этот код целиком, я не могу выложить в открытый доступ, к сожалению.
Да и весь код, достаточный для воссоздания на вашей стороне, есть в статье.
Мне жаль, что потерялся файл в Google Disk (там все было).
Да и статья не претендует на готовое решение, оформленное в виде просто подключаемой библиотеки.
Она была скорее про то, что не так уж это все и сложно.
Попробуйте просмотреть эти куски кода и создать у себя модуль с виджетами, скрипт и обработчик поисковых запросов.
Если будут сложности, пишите в личку.
Все-таки, хотелось бы, чтоб вы немного поняли что это и с какой стороны к этому подходить.
Пользы будет намного больше, чем просто взять в виде либы (черного ящика).
Прямо сейчас мне немного стыдно за качество кода и концепцию вообще, все-таки статья довольно старая.
Сейчас такое же решение есть для Flask, но код я не могу выложить в общий доступ целиком.
Если кому-то интересно, могу похожую статью с общими принципами написать про Wtforms
Предлагали, но это отдельная история, не техническая.
Не думаю, что они будет интересна на этом ресурсе.
Опыт есть, в том числе и в написании калькуляторов для банковских и страховых продуктов,
интеграции нашей системы одновременно с десятком страховых компаний (с банком это решение интеграцией сложно назвать).
Но если для банка есть решение, к которому он привык и которое решает все задачи,
зачем проверенный инструмент менять на что-то другое, неизвестное и страшное.
В него (файл Excel) уже вложены какие-то усилия
и психологически очень сложно просто взять это и выбросить,
заплатить какие-то деньги за что-то неизвестое.
Про этот вариант знаю, но для нас он не подходит, к сожалению.
У нас debian на сервере и разворачивать win-сервер для этой простой задачи не хотелось бы, тем более, решение есть и достаточно простое.
Спасибо, исправил.
И все-таки, лучше в «личку» пишите, если не сложно.
Думаю, сообществу в комментах интереснее читать обсуждение, чем разбор грамматических ошибок статьи.
В нашем приложении каждый пользователь может увидеть разное количество опций одного и того же поля
в зависимости от ролей доступа, параметров документа, различных ограничений доступа.
А хранить копию каждого поле-проект-документ-пользователь замусорит систему и нужно думать о инвалидации кэша, к тому же (параметры у документа меняются и будут менятся список наложенных фильтров).
В этом приложении все более прозрачно.
При отрисовке, виджет выдирает наложенные фильтры из QuerySet-а и сохраняет их в параметрах,
которые каждый раз добавляются к AJAX-запросу.
Необходимости хранить QuerySet вообще нет. Все работает тупо и просто.
Можно открыть 10 документов на разных вкладках и получить разный набор опций для каждого.
Это могут сделать 5000 пользователей и ajax-обработчик будет корректно всех обслуживать.
С моим вариантом это будет работать, а с django-select2 нет.
Автор умеет ими пользоваться.
Замечание верное. Выкладываю в общий доступ все-таки.
Поясню ход мыслей.
На странице бывает много независимых форм в разных местах.
Не хочу после каждой формы выводить {{form.media}}.
Загрузку всех скриптов всегда выношу в конце тэга «body»,
это действительно, ускоряет время отображения страницы (визуально).
В шаблон я предлагал вставить еще кусок шаблона (через include) с модальным окном,
куда загружается дерево иерархии через AJAX.
Можно было дерево загружать возле виджета,
вставлять этот контейнер скриптом после загрузки страницы.
Основная цель статьи не в том, чтоб предложить идеальное решение типа (скачай и забудь), а максимально простое для изучения внутри
Это виджеты для стандартных форм Django и предназначены для использования с формами Django.
В блоке «Использование» как раз пример использования одного из виджетов с формой Django.
Понимаю, что можно и в ногу выстрелить.
Но это просто инструмент. Им нужно пользоваться только тогда, когда это необходимо.
Мы им пользуемся очень редко, так как все разработчики (3 человека) достаточно хорошо знаем SQL.
Чтоб пояснить, что с помощью системы можно очень просто решать задачи, которые чистым SQL реализуются очень сложно,
приведу пример (реальный, между прочим)
В форме задать период и тип группировки (по неделям, месяцам, кварталам)
Получить много таблиц со столбцами периодов, попавших в отчетный с учетом типа группировки.
И детализация чтоб работала (можно щелкнуть на любой цифре и получить детальную информацию по объектам, которые использовались для расчета этой ячейки).
С помощью шаблонизатора решается достаточно просто:
— Сделать запрос, генерирующий поля: date_from, date_to, period_title
мы используем рекурсивные или иерархические (в зависимости от БД) запросы.
в этом запросе известны параметры фильтра и он один на все таблицы (многократное использование)
— Создать запрос типа
select var_name
{% for field in datasets.field_generator %}
,
count(case
when period between to_date({{field.d_from}}, 'dd.mm.yyyy') and to_date({{field.d_from}}, 'dd.mm.yyyy')
then 1
end) as {{field.period_title}}
{% endfor %}
from table
where period between [[f.period.from]] and [[f.period.to]]
group by var_name
XML-настройки для табличного виджета со ссылками детализации генерируется так же.
Как бы, и все.
А теперь попробуйте это сделать как-то по другому, без использования шаблонной системы.
Резюмирую. Это просто инструмент.
Его, конечно, можно использовать не правильно.
Как мне кажется, python намного проще понять из-за отсутствия этих разных значков $, скобок и прочего (глаза разбегаются).
Я обычный быдлокодер с очень поверхностными знаниями в нескольких языках и технологиях.
По поводу «технического долга», это способ поднять узнать что-то новое в новой области.
Им можно воспользоваться, а можно и нет.
Наверное, много велосипедов развелось в последнее время.
Есть из чего выбрать и с кем обменяться опытом.
Это же хорошо, а не плохо.
Ни в коем случае не вынуждаю знакомится с новыми языками.
Считаю своим долгом выложить свои наработки (пользуюсь OpenSource решениями).
Использовать их или нет, каждый решает сам для себя.
Хочется самому проектировать архитектуру, а не подстраиваться под существующие (наверное, это велосипед),
иметь возможность дописать любой функционал, который придет в голову (например, загрузку из Excel и построение отчета по загруженному)
Да и просто интересно написать что-то на python (этот язык просто затягивает).
Теперь понял. Вполне себе вариант.
У нас по такому принципу пишется документооборот.
Он в репозитории тоже есть, только не закончен.
Нам, к сожалению не подходит.
Разработчики отчетов знают только sql
Понятно,
у нас другая специфика.
Такой была первая версия на PHP.
Куча кода тогда накапливается там, и им сложно управлять,
а тут система заставляет придерживаться архитектуры,
то есть больше шансов на парное программирование
или доработку отчета не его автором.
Люди, которые на этом пишут,
не знают ничего, кроме sql.
Да и как-то лезть в код, перезапускать сервер
«не православно»
with t as (
-- select [[f.d_start]] as d_start from dual
select sysdate - 14 from dual
)
select.from table src
cross join t
Возможность вложеных запросов
мы еще не использовали на практике
(эта версия отчетов свежая).
Для этого можно выводить
на страницу отчета прошедший
через пре-процессор код запроса
(в посте это есть в самой последней картинке).
Есть предложения?
По псевдокоду:
про «адский» увидел, но не смог удержаться, простите.
def get_something(id):
if not self.__cached:
self.__cached = self._get_something()
return self.__cached
def set_something(id):
self.__cached = None
....
Тут хорошо подходит идеология обращения через property
Еще вариант (теория)
Могу небольшую модификацию синхронизированного кэша предложить, которая защищена от конкурирующих изменений кэша.
Применимо только тогда, когда обрабатывать данные большой «пачкой» выгоднее, чем по одному и допустимо небольшое устаревания кэша.
При изменениях, id записей накапливаются.
Есть один или несколько (нужен механизм распределения записей по обработчикам) обработчиков.
На cron вешать эти обработчики, чтоб они пачками обновляли кэш не по каждому объекту, а по списку накопившихся.
Конкретика:
Использовал в поддержании актуальности (задержки 10 минут) таблицы по сущности, которая собирается из множества других таблиц в oracle,
когда запрос с join-ами этих таблиц для web-интерфейса отчетности не давал приемлимых результатов.
На все эти таблицы вешались триггеры, которые вычисляли и записывали в таблицу-лог id объекта и время изменения, то есть, накапливали объекты, по которым кэш устарел
Была процедура, которая запускалась раз в 10 минут.
— Сделать view, в которой используются таблицы, по набору колонок равную таблице
— Запомнить время старта
— Выбрать все объекты, которые имеют запись в логе до времени старта
— Накатить все данные из view, которые есть в логе (merge into table using(select * from view where id in (select id from log))… )
— Удалить записи из лога, которые до времени старта (чтобы удалить только гарантированно отработанные, так как при обновлении, успевают налететь еще данные)
На выходе получали таблицу с 50-60 столбцами (все нужные параметры сущности), по которой очень удобно и быстро строить отчеты почти online.
Время инкрементного обновления кэша 40 сек. Если выбирать все записи из представления, то 3 часа.
По моему, провайдеры, как раз, заинтересованы в файлообмене.
Чем больше люди качают, тем большие уйдут на более дорогие
высокоскоростные тарифы
и будут приносить провайдеру больше денег.
А если закрыть торренты, то для чего скорость 30 мегабит?
Люди понемногу сползут на тарифы 1025 Мб/с
Эта статья рассматривает довольно узкие условия, когда нужно просто заменить значения в некоторых ячейках.
Как идея (не проработанная), можно сделать достаточное кол-во пустых строк и просто скрывать не используемые строки, оставляя только те, которые потребовались.
Тогда нумерацию можно не менять.
То есть тогда задача сводится снова к этой узкой области «только редактирование».
Посчитал решение сильно тривиальным и слишком простым для того, чтобы куда-то его выкладывать.
Сейчас я практически не пишу под django, переключился на flask.
Проект, в который входит этот код целиком, я не могу выложить в открытый доступ, к сожалению.
Да и весь код, достаточный для воссоздания на вашей стороне, есть в статье.
Мне жаль, что потерялся файл в Google Disk (там все было).
Да и статья не претендует на готовое решение, оформленное в виде просто подключаемой библиотеки.
Она была скорее про то, что не так уж это все и сложно.
Попробуйте просмотреть эти куски кода и создать у себя модуль с виджетами, скрипт и обработчик поисковых запросов.
Если будут сложности, пишите в личку.
Все-таки, хотелось бы, чтоб вы немного поняли что это и с какой стороны к этому подходить.
Пользы будет намного больше, чем просто взять в виде либы (черного ящика).
Прямо сейчас мне немного стыдно за качество кода и концепцию вообще, все-таки статья довольно старая.
Сейчас такое же решение есть для Flask, но код я не могу выложить в общий доступ целиком.
Если кому-то интересно, могу похожую статью с общими принципами написать про Wtforms
Не думаю, что они будет интересна на этом ресурсе.
Опыт есть, в том числе и в написании калькуляторов для банковских и страховых продуктов,
интеграции нашей системы одновременно с десятком страховых компаний (с банком это решение интеграцией сложно назвать).
Но если для банка есть решение, к которому он привык и которое решает все задачи,
зачем проверенный инструмент менять на что-то другое, неизвестное и страшное.
В него (файл Excel) уже вложены какие-то усилия
и психологически очень сложно просто взять это и выбросить,
заплатить какие-то деньги за что-то неизвестое.
У нас debian на сервере и разворачивать win-сервер для этой простой задачи не хотелось бы, тем более, решение есть и достаточно простое.
Возможно, для кого-то это подойдет.
Вот тут очень хорошо описана работа python с Excel
в том числе, и через честные com-объекты
habrahabr.ru/post/232291/#com
Но у нас серверная часть на debian
И все-таки, лучше в «личку» пишите, если не сложно.
Думаю, сообществу в комментах интереснее читать обсуждение, чем разбор грамматических ошибок статьи.
При регистрации поля в замыкании или в Memcached, в виде ключа используется
github.com/applegrew/django-select2/blob/master/django_select2/fields.py#L50
name = kwargs.pop('auto_id', u"%s.%s" % (self.__module__, self.__class__.__name__))
Так django-select2 достает QuerySet на другой стороне AJAX-а
В нашем приложении каждый пользователь может увидеть разное количество опций одного и того же поля
в зависимости от ролей доступа, параметров документа, различных ограничений доступа.
А хранить копию каждого поле-проект-документ-пользователь замусорит систему и нужно думать о инвалидации кэша, к тому же (параметры у документа меняются и будут менятся список наложенных фильтров).
В этом приложении все более прозрачно.
При отрисовке, виджет выдирает наложенные фильтры из QuerySet-а и сохраняет их в параметрах,
которые каждый раз добавляются к AJAX-запросу.
Необходимости хранить QuerySet вообще нет. Все работает тупо и просто.
Можно открыть 10 документов на разных вкладках и получить разный набор опций для каждого.
Это могут сделать 5000 пользователей и ajax-обработчик будет корректно всех обслуживать.
С моим вариантом это будет работать, а с django-select2 нет.
Замечание верное. Выкладываю в общий доступ все-таки.
Поясню ход мыслей.
На странице бывает много независимых форм в разных местах.
Не хочу после каждой формы выводить {{form.media}}.
Загрузку всех скриптов всегда выношу в конце тэга «body»,
это действительно, ускоряет время отображения страницы (визуально).
В шаблон я предлагал вставить еще кусок шаблона (через include) с модальным окном,
куда загружается дерево иерархии через AJAX.
Можно было дерево загружать возле виджета,
вставлять этот контейнер скриптом после загрузки страницы.
Основная цель статьи не в том, чтоб предложить идеальное решение типа (скачай и забудь), а максимально простое для изучения внутри
В блоке «Использование» как раз пример использования одного из виджетов с формой Django.
Можете конкретизировать вопрос? Постараюсь ответить.
Но это просто инструмент. Им нужно пользоваться только тогда, когда это необходимо.
Мы им пользуемся очень редко, так как все разработчики (3 человека) достаточно хорошо знаем SQL.
Чтоб пояснить, что с помощью системы можно очень просто решать задачи, которые чистым SQL реализуются очень сложно,
приведу пример (реальный, между прочим)
В форме задать период и тип группировки (по неделям, месяцам, кварталам)
Получить много таблиц со столбцами периодов, попавших в отчетный с учетом типа группировки.
И детализация чтоб работала (можно щелкнуть на любой цифре и получить детальную информацию по объектам, которые использовались для расчета этой ячейки).
С помощью шаблонизатора решается достаточно просто:
— Сделать запрос, генерирующий поля: date_from, date_to, period_title
мы используем рекурсивные или иерархические (в зависимости от БД) запросы.
в этом запросе известны параметры фильтра и он один на все таблицы (многократное использование)
— Создать запрос типа
XML-настройки для табличного виджета со ссылками детализации генерируется так же.
Как бы, и все.
А теперь попробуйте это сделать как-то по другому, без использования шаблонной системы.
Резюмирую. Это просто инструмент.
Его, конечно, можно использовать не правильно.
Я обычный быдлокодер с очень поверхностными знаниями в нескольких языках и технологиях.
По поводу «технического долга», это способ поднять узнать что-то новое в новой области.
Им можно воспользоваться, а можно и нет.
Наверное, много велосипедов развелось в последнее время.
Есть из чего выбрать и с кем обменяться опытом.
Это же хорошо, а не плохо.
Ни в коем случае не вынуждаю знакомится с новыми языками.
Считаю своим долгом выложить свои наработки (пользуюсь OpenSource решениями).
Использовать их или нет, каждый решает сам для себя.
P.S.
Привет.
Хочется самому проектировать архитектуру, а не подстраиваться под существующие (наверное, это велосипед),
иметь возможность дописать любой функционал, который придет в голову (например, загрузку из Excel и построение отчета по загруженному)
Да и просто интересно написать что-то на python (этот язык просто затягивает).
У нас по такому принципу пишется документооборот.
Он в репозитории тоже есть, только не закончен.
Нам, к сожалению не подходит.
Разработчики отчетов знают только sql
у нас другая специфика.
Такой была первая версия на PHP.
Куча кода тогда накапливается там, и им сложно управлять,
а тут система заставляет придерживаться архитектуры,
то есть больше шансов на парное программирование
или доработку отчета не его автором.
Люди, которые на этом пишут,
не знают ничего, кроме sql.
Да и как-то лезть в код, перезапускать сервер
«не православно»
Возможность вложеных запросов
мы еще не использовали на практике
(эта версия отчетов свежая).
Для этого можно выводить
на страницу отчета прошедший
через пре-процессор код запроса
(в посте это есть в самой последней картинке).
Есть предложения?
про «адский» увидел, но не смог удержаться, простите.
Тут хорошо подходит идеология обращения через property
Еще вариант (теория)
Могу небольшую модификацию синхронизированного кэша предложить, которая защищена от конкурирующих изменений кэша.
Применимо только тогда, когда обрабатывать данные большой «пачкой» выгоднее, чем по одному и допустимо небольшое устаревания кэша.
При изменениях, id записей накапливаются.
Есть один или несколько (нужен механизм распределения записей по обработчикам) обработчиков.
На cron вешать эти обработчики, чтоб они пачками обновляли кэш не по каждому объекту, а по списку накопившихся.
Конкретика:
Использовал в поддержании актуальности (задержки 10 минут) таблицы по сущности, которая собирается из множества других таблиц в oracle,
когда запрос с join-ами этих таблиц для web-интерфейса отчетности не давал приемлимых результатов.
На все эти таблицы вешались триггеры, которые вычисляли и записывали в таблицу-лог id объекта и время изменения, то есть, накапливали объекты, по которым кэш устарел
Была процедура, которая запускалась раз в 10 минут.
— Сделать view, в которой используются таблицы, по набору колонок равную таблице
— Запомнить время старта
— Выбрать все объекты, которые имеют запись в логе до времени старта
— Накатить все данные из view, которые есть в логе (merge into table using(select * from view where id in (select id from log))… )
— Удалить записи из лога, которые до времени старта (чтобы удалить только гарантированно отработанные, так как при обновлении, успевают налететь еще данные)
На выходе получали таблицу с 50-60 столбцами (все нужные параметры сущности), по которой очень удобно и быстро строить отчеты почти online.
Время инкрементного обновления кэша 40 сек. Если выбирать все записи из представления, то 3 часа.
Чем больше люди качают, тем большие уйдут на более дорогие
высокоскоростные тарифы
и будут приносить провайдеру больше денег.
А если закрыть торренты, то для чего скорость 30 мегабит?
Люди понемногу сползут на тарифы 1025 Мб/с