кнопка править в списке видов занятий не работает; ошибка привводе большого числа предметов

[GoogleCodeExporter]

1) кнопка править в списке видов занятий не 
работает
2) при вводе большого числа предметов в 
расписание либо выдает ошибку, либо 
предметы закрываются картинкой

Original issue reported on code.google.com by uralskia...@gmail.com on 21 Nov 2010 at 10:45

[GoogleCodeExporter]

2)..>либо предметы закрываются картинкой

Да - это проблема - от Максима уже было 
предложение сделать ввод расписания 
вертикальным - так более привычно, и в 
ширину расползаться страница не будет.

Но даже в этом случае в текущую ширину 
страницы мы не впишемся, т.к как я вижу, у 
нас центральная область при необходимости 
по ширине не растягивается.

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

<Балон>Редактировать </Балон> (в текущей 
версии пока можно обойтись без балона)
Расписание:
768 выбрать

Cписки:

Преподаватели
Предметы
Групп
Аудитории
Виды отчётности
Виды занятий

Надписи короче - места больше. 

Кроме этого, сейчас не очень правильно 
сделана реализация левой обрамлящей рамки 
- через отдельный элемент <div id="picture"></div> - по 
этой причине он занимает больше 
горизонтального места, чем мог бы. От этого 
дива как отдельной сущности нужно 
избавиться - фоновую картинку назначить 
уже существующему диву "<div id="left">" (как я 
предлагал в первом примере); проблему 
наезда текста на картинку можно решить 
во-первых, выравниванием картики по 
правому краю, во-вторых установлением 
ненулевого значения свойства padding-right для 
этого же дива (текст внутри дива не будет 
приближаться к правой границе ближе, чем на 
указанную величину).

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

Это важная проблема - в текущем виде она не 
позволит в деканате создать полноценное 
расписание.

Original comment by bender...@gmail.com on 22 Nov 2010 at 8:54

• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

>>1) кнопка править в списке видов занятий не 
работает

Работает.

>>2) при вводе большого числа предметов в 
расписание либо выдает ошибку, либо 
предметы закрываются картинкой

эхх...
Как повторить ошибку - я не понял.
С перекрытием...  Вертикальной таблицу 
делать не разумно.

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

Original comment by Lockyw...@gmail.com on 22 Nov 2010 at 10:52

[GoogleCodeExporter]

>Дней в неделе у нас всегда семь. А пар редко 
когда бывает больше 6. Значит 
горизонтальная таблица практически всегда 
будет шире вертикальной.

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

Кроме того, я не исключаю в перспективе 
(правда, не в ближайшей) того, что мы захотим 
доработать структуру таблицы так, чтобы 
она лучше соответствовала шкале времени 
(например добавлением фейковых ячеек или 
чего-то похожего) - например сейчас у нас на 
одном и том же уровне находятся занятия, 
начинающиеся в 9:45 и в 10:00. Для визуального 
восприятия общей картинки таблицы может 
быть лучше, чтобы это были разные уровни. 
Соответственно, вся таблица уже не будет 
квадратом - если в один день утром 4 занятия, 
а в другой день - вечером 3, то недельная 
таблица будет в длину не 4 ячейки, а 7. Не 
уверен, что мы соберемся это делать, но эту 
возможность нужно тоже учитывать.

В общем, как бы там ни было, нам нужна 
работающая возможность автоматического 
расширения страницы по горизонтали или по 
вертикали - рассчитывать на то, что у нас в 
один день не может быть более 6ти-7ми 
предметов мы не можем.

Как это будет сделано - по горизонтали или 
по вертикали - мне не принципально. 

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

В пользу горизонтальной прокрутки в голову 
приходит только одно:
- горизонтальная шкала времени при 
правильной реализации (если не будет 
вертикальной прокрутки) будет выглядеть 
также довольно естественно (в голову 
приходит например график какой-нибудь 
эволюции, где время имеет направление 
слева направо).
- если будет гарантированное отсутствие 
вертикальной прокрутки (7 дней убираются по 
вертикали), первый пункт из предыдущего 
раздела (про зло горизонтальной прокрутки) 
можно будет не брать во внимание, т.к. в 
специальных ситуациях иногда разумно 
отступать от общепринятых правил, если 
того объективно требует ситуация. 
Одновременно горизонтальной и 
вертикальной прокрутки у нас не должно 
быть ни при каких обстоятельствах.

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

Original comment by bender...@gmail.com on 22 Nov 2010 at 11:54

[GoogleCodeExporter]

Сейчас отношение области меню к области 
центральной части страницы - 1:2, на макетах, 
которые делала Юля - почти 1:5. Считаю, что мы 
можем сделать такое отношение частей и в 
жизни, путем исправлений предложенных 
Антоном "надписи короче - места больше"

Что касается вертикального и 
горизонтального расположения. Я за "дни 
недели по горизонтали", т.е вертикальное 
расписание, по причинам описанным Антоном. 
К тому же если мы сделаем вертикальное 
расписание, то можно будет его вставить 
вместо списка на экран "Расписание на 
неделю" пользовательского интерфейса.

Original comment by andrej.k...@gmail.com on 22 Nov 2010 at 12:59

[GoogleCodeExporter]

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

2010/11/22 Lockywolf __ 

>    В пользу горизонтальной прокрутки есть 2 
очевидных аргумента. первый -
>    высота ровно точно 7 дней. 

А в пользу вертикальной есть другой 
аналогичный аргумент - ширина всегда равна 
точно 7 дней, так что это не прокатит :)

>   второй - в хтмл легко сделать таблицу с
>    разными рядами но очень тяжело с разными 
столбцами. ибо тег "строка"
>    есть, а тега "столбец" нету.

Ну каже же - есть td (колонка). Соглашусь, что 
в цикле вытягивать строки по горизонтали в 
каком-то смысле логичнее, чем по вертикали 
(т.к. колонки входят в состав строк, а не 
наоборот), но про "очень тяжело" не согласен 
- логика довольно простая:

<table>
while(has_more_rows) {
    lecture_index++;
    <tr>
        <td>monday[lecture_index]<td>
        <td>tuesday[lecture_index]<td>
        <td>wednesday[lecture_index]<td>
        <td>thursday[lecture_index]<td>
        <td>friday[lecture_index]<td>
        <td>saturday[lecture_index]<td>
        <td>sunday[lecture_index]<td>
    </tr>
    has_more_rows = lecture_index < monday.size() && lecture_index < tuesday.size() && ... && lecture_index < sunday.size();
}
</table>

Схема конечно же сильно упрощена - нужно 
вставить проверки на индексы массивов и 
прочие детали, но смысл должен быть ясен - 
для каждой строки по порядку пробегать по 
дням недели - на первой строке будут все 1е 
лекции из каждого дня недели, на 2й строке - 
вторые и т.п.

В общем, цикл наверное немного усложняется 
по сравнению с тем, что скорее всего есть 
сейчас, но не настолько, чтобы стать 
непреодолимой преградой.

Original comment by bender...@gmail.com on 22 Nov 2010 at 1:02

[GoogleCodeExporter]

> <table>
> while(has_more_rows) {
>    lecture_index++;
>    <tr>

Кстати, вместо этого есть более элегантное 
решение, которое будет вписываться в 
старую логику циклов - если не использовать 
таблицы, а дивы в режиме таблиц, с которыми 
недавно ознакомился Максим.

Цикл будет примерно такой:

<div display="table">
<div display="table_row">
for(week_day : week_days) 
{
    <div display="table_cell">

    for(lecture_index : week_day.lectures.size()) 
    {
        <p>week_day.lectures[lecture_index]</p>
    }
    </div>
}
</div>
</div>

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

Original comment by bender...@gmail.com on 22 Nov 2010 at 1:27

[GoogleCodeExporter]

Еще раз напоминаю: просьба для добавления 
сообщений по тикетам использовать 
веб-интерфейс - это в рассылку vkurse_issues к 
сожалению работает только в одном 
направлении.

>>В общем, цикл наверное немного 
усложняется по сравнению с тем, что скорее 
всего есть сейчас, но не настолько, чтобы 
стать непреодолимой преградой.

>Цикл заметно усложняется.
>Я же и попытался сначала так писать.

Да, цикл конечно кривоват - поэтому с дивами 
может быть более приятным решением.

>На самом деле, на 1280х1024 все отлично видно в 
горизонтальном виде.
>На счет дивов... ну, попробовать можно.
>Но это все равно не отменяет потребности 
вписать все это в страницу.

На этой странице названия предметов "testing" 
слишком короткие - 
http://vkurse.innolab.net.ru:8180/vkurse/week2.jsp?group=8&submit=OK

В реале я думаю вместо 15ти предметов при 
этой же ширине уместится только 5. Ты можешь 
побыстрому попробовать сделать прототип 
страницы с вертикальной версткой, в 
которой по горизонтали были бы все дни 
недели от понедельника до воскресенья, но 
при этом предметы были реальные (т.е. с 
реалистичной шириной)? Если все 7 дней 
объективно будут не влезать, то возможно 
правда остановимся на горизонтальной 
прокрутке, только сделанной понормальному 
- сейчас просто сложно сравнивать.

>Мне кажется, что для демонстрации в 
деканате и сбора фидбека это уже
не особенно нужно.

Для демонстрации нам сейчас на 100% мешает 
наезд боковой картинки на расписание - это 
не позволяет создать нормальное рабочее 
расписание на неделю. Проблема решается 
или вертикальным расписанием или 
автоматическим расширением по 
горизонтали. Хочется услышать комментарии 
от Максима - если он сможет побыстрому 
сделать авторасширение так, что наезда на 
предменты не будет, такое решение сейчас 
тоже пройдет.

>Создайте отдельный тикет на тему того, что 
еще нужно для демонстрации
в деканате.

О других проблемах пока не сообщалось - 
сейчас эта проблема самая важная и 
единственная.

Original comment by bender...@gmail.com on 22 Nov 2010 at 2:20

[GoogleCodeExporter]

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

Original comment by budakovsky on 22 Nov 2010 at 7:44

[GoogleCodeExporter]

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

Original comment by budakovsky on 24 Nov 2010 at 9:13

[GoogleCodeExporter]

Спасибо! багу закрываю

Original comment by bender...@gmail.com on 24 Nov 2010 at 9:47

• Changed state: Fixed