Система отчетности на базе КГУ

Алексей, исходная постановка задачи, которую пока только обсуждаем https://docs.google.com/document/d/1xJuC0npLxERikPl82hU9PacW_0T29kDsy08OUBJr9MA/edit

Нашел еще вот такие интересные решения, они платные, но стоят не дорого и мне кажется стоит попробовать их
1. Пример один: http://themes.themepunch.com/?theme=megafoliopro_jq, настройки сетки (хорошо видно как перекомпоновка происходит) http://joxi.ru/DCk4Utg5CbAEJNOeNoc
2. Пример 2: http://codecanyon.net/item/melonhtml5-metro-gallery/3579821?ref=leli2000, демо http://www.melonhtml5.com/demo/metro_gallery/, настройки сетки http://joxi.ru/sCk4Utg5CbCjI12YeFw

Посмотрите предлагаемые готовые варианты реализации.
Можно ли их нам встроить в систему, а потом выводить в отчет в таком же виде?

ок, решения проанализируем.
в исходном файле вы видели мой комментарий-вопрос по поводу пунктов 4-10, который я написал сегодня?

видел, пока предлагаю не смотреть на ТЗ, может быть этими скриптами все решим

Проанализировали готовые скрипты:
1. обрезает фотографии, не умеет размещать фото в ограниченном блоке
2. не умеет размещать фото в ограниченном блоке. 
Ограниченный блок предполагает не только ограничение по ширине, но и по высоте.

1. Там обрезка происходит незначительно (т.е. скрипты стараются минимум обрезать), лучше эксперементально на реальных фотках будет посмотреть
2. Что такое ограниченный блок?

1. мы на реальных и смотрели
2. ограниченный блок - блок, ограниченный по ширине И высоте. то есть прямоугольник.

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

Алексей по вопросу 2, может мы друг-друга не понимаем? Я поставил вместо 100% - 800 px, и у меня фотографии стали меньше по размеру и сузилась картинка http://joxi.ru/VYtCUtg5CbA6b5tOTeI по высоте так просто не получилось, видимо из-за того что скрипт пытается несмотря на указания вывести все фото.

Андрей, я об этом и говорил. не умеет размещать фото в ограниченном блоке. ограниченный блок - блок с фиксированной шириной _И_ высотой (одновременно).

можно ли скрипт допилить (желательно), или сделать аналогичный с действующим ограничением по высоте?

Алексей?
Этот вопрос нам надо решить в приоритете, отчет уже согласован и утвержден, осталось разобраться с фотографиями и можно будет делать.

Алексей, какой статус задачи?

Андрей, анализируем, сегодня постараюсь сориентировать.

Андрей, готовы выводы.
Изучили этот вопрос внимательно и пришли к тому, что есть два направления, по которым можно двигаться:

1. Разместить как можно больше фотографий в блоке:
В данном случае необходимо использовать именно алгоритмы упаковки, но тогда страдает внешнее отображение.
Например, такие алгоритмы http://xdan.ru/2d-bin-packing-with-javascript.html или http://codeincomplete.com/posts/2011/5/7/bin_packing/

2. Более важно красиво вывести фото:
В данном случае можно пробовать размещать фото в строки ( например http://jquery-gp-gallery.ionelmc.ro/demo/) или же в столбцы ( напримерhttp://sapegin.github.io/jquery.mosaicflow/). В результате получаем более симпатичный вывод, но некоторые фото могут быть больше/меньше остальных и мы не можем на это повлиять.

Важный момент: если мы выбираем автоматическое размещение фотографий (пересчет при добавлении новой или удалении фотографии), то вручную вмешиваться в построение фотографий мы не можем (ресайзить и накладывать фото друг на друга). Будет доступен ротейт и изменение очередности(стрелочки влево/вправо, не драгебл).

Все вышеупомянутые скрипты (и те что вы присылали), в том виде котором есть, мы применить не можем. Можем взять только идею построения блоков и перенести в нашу систему. То есть использовать их код в нашей системе не получится, к сожалению.

Алексей, главная задача - сделать красиво.
Если готовые не получится использовать - делаем свой, на основе готовых.
Фото у нас без рамок, отступы между фотографиями можно посмотреть в согласованной уже версии отчета https://basecamp.com/1815659/projects/3696812/todos/60698512
Сориентируйте по срокам, сколько займет разработка?

А от чего отталкиваться - от "Исходники дизайна отчета" или от "Исходники 2 этого этапа"?

Только увидел сообщение.
Берите 2-й этап, вообще там одинаковые отступы должны быть

Андрей, проанализировали с программистом новый PDF. 
Он в корне отличается от текущего.
И если к нам в систему его нужно внедрять в таком виде и строить автоматически, то компоновка фото это самая последняя проблема, которая у нас есть в данный момент времени.

Есть 4 основные момента/проблемы, которые я хотел бы обсудить (на примере concept_2etap.pdf):

1. Стр. 2, номер 1. 2 колонки. Это очень важный и проблемный момент. Изначально и сейчас у нас в систему заложена 1 колонка. И всё рассчитано на это. Чтобы сделать 2 колонки я так навскидку даже не представляю, какой набор действий нужно сделать. Основной вопрос - как это реализовать со стороны администратора. Сейчас блоки меняют свою высоту и двигаются вверх вниз - и эта логика достаточно сложная. А внедрить сюда 2 разные колонки - это значит усложнить всё ещё. Я не говорю, что это нереально, но это один из основных проблемных моментов нового PDF. Так ли важны эти 2 колонки?

2. Стр. 2, номер 2.1. 2 заголовка на странице. Опять таки сейчас в системе только 1 заголовок. Если надо несколько - значит нужно вводить в систему какие-то дополнительные типы блоков и вводить их сначала в админку, затем в PDF. Это не так сложно, как 2 колонки, но тем не менее это тоже надо обсудить и обдумать. Нам обязательно это нужно?

3. Стр. 2, 3.3. Справа расположены 4 картинки. Расположены они красиво. Но они собраны таким обрзом вручную. При автоматической компоновке фото, которое мы обсуждаем и планируем сделать - автоматичеки 4 фотографии в таком прямоугольнике расположены в таком виде не будут. Скорее всего - это будет менее красиво. Я просто уточняю, чтобы мы правильно друг друга понимали. Я и вы верно понимаем этот пункт?

4. Стр. 2, 4.1. Блок под "Телефон-автомат МФЦ" я вообще не совсем понял. 5 фоток + текст на месте 2х фоток. Что это такое и что с этим делать? Здесь и текст и автоматически расположенные фотки в Г-образной форме? Вы хотите, чтобы такие формы тоже автоматически сами располагались?

Так что до просчёта механизма расположения фотографий нам нужно утрясти вот эти моменты.

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

Ммм... то есть текущий PDF в систему внедрять пока не нужно? 

> сделать отступы между фото как на дизайне, убрать рамки для фото которые есть в примерах скриптов
А можете тыкнуть стрелочкой, какие именно отступы и рамки имеете ввиду?

Да, PDF это отдельная большая задача, в рамках этой задачи сначала надо разобраться с картинками

Ага, понял, ок, отлично
Тогда давайте уточним ещё по отступам и рамкам.

По отступам: на печати расстояние между фотографиями сверху/снизу в одном блоке должно быть 3 мм. Никаких рамок у фотографий.

Про рамки ясно. Про отступы - не совсем. 3 мм в одном блоке между всеми фотографиями или что-то другое имеется ввиду?

3 мм в одном блоке между всеми фотографиями - да

Алексей, как дела с задачей?
Когда можно будет посмотреть что в итоге получается?

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

И скорее всего когда будем переносить в действующую систему, надо будет сохранить предыдущие отчета в исходном виде (если такое возможно)

Добрый день, Андрей.
Работаем. Задача не простая. Пробуем, анализируем сторонние решения, разрабатываем своё. Пока всё в процессе. Точнее сказать ничего не могу. 
Насчёт примечания - да, так и делаем.

Алексей, необходимо все-таки ограничить какие-то рамки. Что-бы понимать что сделано, что предстоит и какие переспективы, что-бы как минимум вовремя остановится.

Предлагаю завтра в районе 11-12 часов по Москве в скайпе обсудить что было достигнуто, и что требует еще проработки по задаче

Как я и сказал, сейчас я пока не могу дать никакие ориентиры. Но я вас понял, Андрей. Завтра я подробно обсужу ситуацию с программистом и напишу вам примерную оценку по времени, что сделано, что предстоит сделать.

Алексей, обновите статус задачи.
Что сделано и что осталось, думаю уже можно на текущий момент обозначить какие-то сроки.

Сейчас занимаемся последними проверками и отладками по этой задаче. Планируем сегодня залить всё на сервер для демонстрации.

Полностью отключить сохранение данных в тестовом режиме не удалось (для этого создал новый отчет).

Загрузил отчет в тестовую волну, что бы не испортить текущих отчетов.

Для тестирования системы распределения фото сделана тестовая страница http://chat.websumy.ru/inside/kgu/edit_admin_test/568
Для редактирования этого отчета доступна и текущая версия отчета http://chat.websumy.ru/inside/kgu/edit_admin/568.
редактирование текстовых блоков в тестовой версии сейчас полность не работает (сейчас в разработке).

не рекомендую проверять эту систему на текущих отчетах (для предотвращения проблем).

Посмотрел, неплохо, но есть много замечаний:
Баг: растянул область изображений на всю страницу, добавил фотографий http://joxi.ru/1hldUtg5CbAsGBa9M2U, потом по одной удалил несколько штук, уменьшил область фотографии, а все которые удалил там снова оказались http://joxi.ru/nhpdUtg5CbCmGNYvO4U

Примеры компоновки:
1. http://joxi.ru/1hldUtg5CbAsGBa9M2U - идеальный вариант
2. http://joxi.ru/BhpdUtg5CbB4HuOALVM - совсем не то, пустого места не должно быть
3. http://joxi.ru/MBpdUtg5CbB5HinxXWA - в нижнем ряду нарушились зазоры между фото
4. http://joxi.ru/URpdUtg5CbBJGSx3o6c - появилось пустое место
5. http://joxi.ru/aRpdUtg5CbChGIAjy8g - вообще все криво
6. http://joxi.ru/fhpdUtg5CbCeHh6bhW8 - нарушены зазоры между фотографиями
7. http://joxi.ru/wxpdUtg5CbB4Hrr5pcs - нарушены зазоры

Баг исправлен.

Пункт 7 из задания по улучшению:
«Относительно друг-друга и границ блока, в одном блоке фотографии всегда выравниваются по центру». 
(можно сделать выравнивание по левому блоку, а не центровку, но тогда может быть пустое место справа)

По поводу примеров:

1. К этому и стремились.
2. Это тот же набор фотографий, что и с первом примере, но с уменьшенной высотой, а значит для этой высоты и очередности фотографий не возможно высчитать лучшее расположение.
3. Фото с нижнего ряда располагается согласно пункта 7.
4. Это оптимальное размещение для данного набора фотографий. Если перенести фотографию с клубникой на второй ряд, то первые 2 фото должны растянуться (что бы заполнить все пространство по ширине) пропорционально, при этом будут занимать больше места по высоте и скорее всего какая-то из фото 2-го ряда просто не влезет по минимальным критериям. По этому этот вариант отбрасывается.
5.Скрипт рассчитал место относительно пропорций фотографий, но во второй фотографии не достаточный размер чтобы заполнить все пространство, то есть мы видим ее максимальный размер.
6. Аналогично примеру 5.
7. Фотографии размещаются на одинаковом расстоянии от краев и друг друга. Фотографиям не хватает высоты — они ею ограничены. Сделано на основании пункта 7 из задания по улучшению

Критерии, по которым работает скрипт:
1. Показать максимальное к-во фотографий.
2. Фотографии должны стремится к одинаковым пропорциям.
3. Размещаются фотографии по очереди.

Пункт 7 из задания по улучшению:
«Относительно друг-друга и границ блока, в одном блоке фотографии всегда выравниваются по центру».
(можно сделать выравнивание по левому блоку, а не центровку, но тогда может быть пустое место справа)

говорил выше, что на ТЗ пока не смотрим, и нам нужен аналог того как работает в скриптах, которые давали для примера, они работают идеально, за исключением того, что нельзя ограничить по высоте и у картинок есть рамки

То что получилось сейчас, совершенно не годится.
2. В этом случае, часть фотографий должно было бы переместится из верхнего ряда в нижний
3. на ТЗ не смотрим
4. Можно поменять местами капусту и рябину
5. По пропорциям - можно обрезать немного фотографии если в этом есть необходимость, так работают и скрипты предложенные для примера
6.  Тут даже обсуждать сложно
7.  На ТЗ не смотрим

Алексей, как вариант, который поможет достичь нужного эффекта. 
Вот у скрипта http://joxi.ru/WG9eUtg5CbDYSUwnkZc есть настройки, которые позволяют в какой-то мере манипулировать компоновкой, если бы менеджер смог поиграть с сеткой также после размещения фото, то это могло бы помочь.
Но сам скрипт безусловно тоже надо дорабатывать, сейчас хорошо получается только в идеальном случае, шаг влево/вправо - все ломается.

Все приведенные ранее скрипты не идеальны и результаты их работ не идеальны. Они также не могут гарантировать отсутствие пустого места, у них задача стоит просто распределить красиво фото, не ограничиваясь размерами блока. У нас же задача усложняется ограниченными размерами блока.

Сейчас фото в блоке сохраняют очередность и размещаются строго по ней (можно влиять на очередность в панели управления фотографией) и сохраняют пропорции (мы видим все фото).

Можно сделать вот что:
- убрать увеличенные отступы (если не полностью заполнен ряд)

- изменять очередность фотографий в скрипте

это должно дать более выгодное распределение (за исключением, если все фото одного размера).

Повлечет за собой увеличение повторений в размещении фото, может перерасти в замедление процесса распределения (чем больше к-во фото тем больше время).

Обрезание краев фотографий по идеи должна улучшить распределение, НО она повлечет за собой: 
- изменение страницы редактирования отчета клиентов
- выгрузки PDF

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

Желательно использовать, если требуется небольшая обрезка.
Обрезание краев фотографий по идеи должна улучшить распределение, НО она повлечет за собой:
- изменение страницы редактирования отчета клиентов
- выгрузки PDF

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

Алексей, уже стало значительно лучше. Но проблемы, особенно при удалении и когда картинок мало еще хватает:
1. Добавил одну http://joxi.ru/5fBoUtg5CbDoI2mxS-c
2. Добавил вторую http://joxi.ru/L_FoUtg5CbDZJsGCOoU
3. http://joxi.ru/R_JoUtg5CbCdLHveqIc здесь не хватает волшебной кнопки, которая перекомпонует всю страницу
4. Удалил одно фото http://joxi.ru/hvJoUtg5CbASLFm4A4E

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

Сейчас сделали, чтобы картинка могла увеличиваться больше своего оригинального размера, теряя в качестве.
Посмотрите, пожалуйста.

Алексей, я могу только сказать "Вау!" это работает и работает отлично.
Улучшать еще будем, но сейчас это уже реально работающий механизм.
Что еще осталось сделать по компоновке?
Если ничего, то я покажу Галине, чтобы она сказала чего не хватает или неудобно вдруг.

Отлично, Андрей, хорошо, что мы таки пришли к чему-то)
По компоновке на текущий момент мы сделали всё, что хотели.
Так что ждём комментариев/замечаний.

Алексей, Галине все понравилось.
для PDF сделали вывод фото?

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

Старые отчеты сохранятся в текущем виде?
PDF надо каким-то образом протестировать перед выкладкой на прод.
Я бы предложил сделать еще одну копию backend и преобразовать в нем все старые отчеты в новый вид, что-бы посмотреть что в итоге получается

Андрей, насчёт PDF проблем не будет - мы просто передаём туда координаты картинок и они располагаются. То есть в срезе нового алгоритма в PDF просто будут идти другие координаты и всё. Делать какой-то отдельный механизм для проверки PDF можно, если вы хотите, но тратить на это время, честно говоря, не вижу резона.

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

В общем итог такой: нужна КОПИЯ системы с новым полностью работающим функционалом. А так же преобразованными старыми отчетами, чтобы открыть 20-30 и посмотреть не сломалось ли там что-то и как выполняется компоновка при самом разном количестве фотографий. Эту копию можно будет использовать в дальнейшем как тестовую, так как систему будем еще серьезно допиливать под универсальный инструмент.

>>> А так же преобразованными старыми отчетами

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

>>> нужна КОПИЯ системы с новым полностью работающим функционалом

то есть 2 копии должны быть полностью друг от друга автономные?

1. Пусть вручную
2. Да, 2 автономные копии

Кстати, Андрей, мы придумали одно решение: по сути, мы можем на тестовой странице сделать сохранение в базу. Соответственно, отчеты, открытые через новый редактор будут сохранены с новой компоновкой. Старые отчеты и старая компоновке останется по прежнему адресу. То есть, открывать и редактировать отчет можно будет в двух редакторах по разным адресам.

Алексей, нам все равно делать копию проекта.
Так как изменений помимо текущих будет много и они могут быть серьезными.

Занимаемся этим.

Копия проекта с новым механизмом компоновки фото: http://kgu.websumy.ru/inside/

Чтобы старый отчёт обновился - нужно перейти на него и пройтись (просто пролистать) по всем страницам (чтобы применился JS скрипт распределения).
Возле страницы сейчас есть надпись "не заполнено". Это значит, что отчёт там сейчас старый. 
После прохода по страницам - эта надпись исчезнет - это будет значить, что можно скачать уже новый отчёт.