Трекер из кубиков
 

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

Посмотреть это чудо-юдо можно по адресу http://popov654.pp.ru/livemarks
Логин admin, пароль test

Не сочтите за рекламу) Также принимаю замечания на тему того, что сделано плохо и что можно улучшить.

Большая просьба не нажимать на кнопку Сохранить внизу, иначе база рухнет, поскольку PHP-скрипт записи остался старый (пока), и он отсчитывает всё по модулю 50, тем временем как длина строки теперь 40 в каждом блоке. Поэтому если случайно туда нажать - что я однажды по сути уже сделал, вызвав form1.submit() и забыв перед этим переназначить обработчик формы (action) - то таблица рухнет и получится мусор.

Кстати, по кубикам можно ещё и кликать! (изначально они задумывались лишь как индикатор позиции)

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

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

Есть идея вести некий список id полей, которые были модифицированы (ну хотя бы в которых побывал фокус ввода). Но тут есть проблемка - время сохранения. Допустим, пользователь нажал на кнопку смены страницы. Данные надо срочно сохранить, иначе мы их потеряем. Можно вывести confirm на всякий случай. Но дело в другом. Если пользователь специально жмёт кнопку Сохранить, которая не вызывает перехода к другому скрипту, мы можем предположить, что он готов подождать. Можно даже анимацию какую-нибудь вывести.

Но вот если он хочет перейти на другую страницу, и вдруг у него всё молча повисает... это явно не камильфо :) Вывод confirm-а сгладит впечатление, но не полностью. Анимация? Ну разве что... Беда в том, что запросов может быть очень много - максимум 40*30 = 1200, и это при том, что в классе лишь 30 учеников (а вдруг чуть больше?)
Меня это здорово беспокоит. Раньше, конечно, уходило на сервер полторы тысячи записей, но во-первых при доступе через Интернет, а не через локалку ждать приходилось секунд 8-10 даже при неплохом канале (замерял правда весной 2008 года), но там хоть было видно в браузере, что загрузка идёт и всё такое. А тут что, тишина будет?

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

Упс(
Я же во всех браузерах вроде бы проверял(( Правда лишь под XP
Завтра ещё раз проверю в Хроме... Может, версия новая? А в других нормально?

Хм) Похоже проблема всё же в браузере. Только что проверил в FF 6.0 и Opera 11.50, всё почти отлично. "Почти" - потому что шрифт где информация о номере страницы почему-то совсем не 11 пикселей (больше гораздо), а в Опере ещё и уехал слегка вправо. Но по сравнению с этим ужасом это пустячок :D
Впрочем, всё равно надо будет подправить)

Со шрифтом я даже знаю почему - я опять указал только число, забыв добавить 'px'. Поэтому все, кроме IE, восприняли это как пункты, а не пикселы :)

Всё, теперь гораздо лучше)
Насчёт браузеров - я в своё время дважды проводил оптимизацию под разные модели, и у меня на самом деле там нехило всяких условий и проверок UserAgent стоит (в PHP коде, так что их не видно). Но Хрому я похоже в последний раз не уделил внимания) Зато тестил в Netscape 8 и 9, Safari и древних версиях Mozilla (начиная с 1.5). Модуль редактирования везде отображается без ошибок, со страницей входа в Mozilla версии ниже 3.0 чуть хуже: там поля ввода вместе с подписями уезжают к правому боку картинки, а должны быть у левого :)

Недавно задумался о том, что, мол, нехорошо в PHP коде сочетать и логику, и представление, причём почти рядом, и решил заботу о браузерах переложить на JS и CSS. Но потом как следует подумал, и понял что в моём случае этого делать явно не стоит: оказалось, что 4-5 переменных с семантическими именами, периодически вставляемые в генерируемую HTML разметку как атрибуты - это гораздо проще, чем куча CSS классов и JavaScript кода. И гораздо лаконичнее по объёму. Более того, учитывая, что первый вариант уже был реализован, на переделку можно было угробить 1-2 дня и кучу раз запутаться по дороге) Так что я оставил эту бесполезную затею :)

Да ёшкин же кот... :D
Просил же не нажимать сохранение))

канешн :lol:

Злые вы :D
:haha: