API тоже иногда меняется :) Хотя legacy-кода там могло бы быть и поменьше. Насчёт прожорливости учту — чаще всего WordPress для клиентов приходится переносить на виртуальный сервер, с лимитом времени на скрипты бывают проблемы.
Немного смущает, что этот плагин уже полтора года не обновлялся. В какой-то момент он может начать некорректно отрабатывать на новых версиях WordPress. Но в целом относительные пути — это отличная вещь.
И не только в визуальный. Я plaintext-редактор использую — штатный загрузчик изображений и туда вставляет полные пути. Вот прямо сейчас проверил на свежем WordPress 4.1 — ничего не поменялось. В принципе, можно каждый раз ручками править, но оно кому-то надо? Не так уж часто с домена на домен приходится переносить.
Ссылки, которые хранит сам WordPress у меня за 6 лет ни разу не было проблем (в плане замены). Не один десяток сайтов так перенёс. Возможно, могут быть проблемы с плагинами, которые хранят ссылки как-то нестандартно.
Что касается сериализованных данных, то не вижу особых проблем — если всё делать аккуратно, ссылки в «наборах» прекрасно заменяются.
Но за ссылку на утилиту — спасибо, интересная штука, надо будет попробовать.
При переносе с localhost'а на реальный сервер нельзя забывать про адрес сайта. Смена домена с одновременным переносом по вашей инструкции сделает сайт абсолютно неработоспособным. По-этому в инструкцию стоит добавить ещё один шаг (актуальный при смене домена, в т.ч. — при переносе с локального сервера на боевой). Для примера будем считать, что сайд переносится с домена mysite.local на домен mysite.ru.
В сохранённом дампе базы данных WordPress ищем все вхождения mysite.local и заменяем на mysite.ru. Можно это сделать в любом нормальном текстовом редакторе (например, Notepad++). После замены аккуратно сохраняем БД, не забывая о кодировке (в случае с более или менее современными версиями WordPress нужна кодировка UTF-8 без BOM).
Если говорить о клавиатурах с переменной раскладкой, то стоит упомянуть ещё лебедевский «Оптимус». Идея, в целом, интересная — по дисплею в каждой кнопке.
Уже не помню, как там в Delphi, а в Lazarus со вводом даты проблем вообще нет — есть отличный компонент TZVDateTimePicker, который при ручном вводе всё лишнее фильтрует (ну и выбрать из календаря позволяет, да). Разделитель при этом используется системный. Дальше — дело техники: в базу пишем значение даты, преобразованное в UnixTime, а при выводе — преобразуем обратно (при таком раскладе о разделителе можно сильно не беспокоиться).
Всё зависит, опять-таки, от данных. Вернёмся к исходной теме поста. Скажем зачем забивать пользователю голову такой ненужной информацией, как тип десятичного разделителя? С точки зрения пользователя важно ввести данные (быстро и правильно). Если мы заставим его думать над тем, запятую ему вводить, или точку — он будет отвлекаться от основной работы.
Другое дело, когда данные вводятся в достаточно свободной форме — тогда имеет смысл сообщать об ошибке (по возможности — не модально).
Excel — это вообще отдельная тема, в силу своей универсальности он позволяет очень многое, перекладывая ответственность на пользователя. Там и не может быть никакой фильтрации (хотя из-за этого тоже свои заморочки).
Но мы же говорим о разработке собственного ПО, а здесь именно на нас, как на разработчиков, ложится ответственность за удобство работы. Разумеется, всегда нужно исходить из конкретной задачи. В конце концов, это программа должна быть инструментом (удобным!) в руках пользователя, а не пользователь — инструментом (сам-себе-валидатором) в руках программы.
Даже если взять АРМ, которым пользуются в небольшой конторе, допустим, 8 человек. Допустим, сейчас это 8 опытных сотрудников, которые хорошо знают, что и куда вводить в формах — их можно строго не ограничивать. А если завтра на их место придут новые сотрудники, плохо знакомые с устоявшимися принципами ввода данных? Вот чтобы они дров не наломали, нужно внимательно следить за вводом, ограничивая возможность ввода некорректных данных.
Преобразование в число — это само собой. Но тут тоже есть подводный камень. (всё дальнейшее рассуждение относится прежде всего к desktop-приложениям, в частности к написанным в Delphi-подобных IDE) Если, допустим, мы не фильтруем ввод, а валидацию проводим при отправке формы, то высока вероятность при попытке преобразования получить системное исключение. Понятно, что его не проблема отловить и обработать. Но при этом нам придётся вывести пользователю сообщение об ошибке. А это, в свою очередь, выбивает пользователя из «потока», отвлекая его от основной задачи — ввода данных.
PS. На эту тему (информирование пользователя об ошибках ввода) очень хорошо написано у Купера в «About Face» — рекомендую к прочтению всем, кто проектирует интерфейсы.
Что касается опасности, то тут как минимум два нюанса. Во-первых, чем «свободнее» ввод, тем строже должна быть валидация. Это само по себе не проблема. Во-вторых, при копировании вероятность ошибки оператора в ряде ситуаций повышается (в сравнении с ручным вводом). К примеру, оператор копирует в поле ввода число 11127634,44 — если оператор случайно не выделит первую или последнюю цифры при копировании, то шанс, что он заметит ошибку ниже, чем если бы он вбивал числа вручную, глядя из окна в окно.
PS. Повторюсь, всё зависит от конкретного случая, где-то копипаст необходим, но не везде.
Имхо, многое зависит от конкретного случая. Например, есть АРМ, где оператор вводит финансовые значения в диапазоне примерно от 10 до 2000. Значения вводятся «с листа», т.е. всегда с бумажного носителя. Нужен там копипаст? Нет.
В других случаях, да, без копипаста не обойтись, но, как я уже сказал, тогда нужна строгая валидация и зачистка.
Я в таких полях (не текстовых) обычно блокирую вставку из буфера. Но в принципе, можно отлавливать вставку из буфера и чистить приходящее значение. Как бы в любом случае при отправке поля в SQL-запрос надо следить за содержимым, а вставленное из буфера содержимое потенциально, имхо, более опасно, чем ввёдённое с клавиатуры (поскольку может содержать чёрте что).
Такой вариант тоже возможен. Единственный нюанс — если введённые данные дальше попадают в SQL-запрос, то при отправке формы запятую придётся либо заменить, либо экранировать.
Кстати, в случае с ноутбуком быстрый ввод десятичного разделителя представляет собой ещё большую проблему — встречал модели, у которых клавиша "?/.," была сдвинута.
Ну и нумпады есть далеко не у всех моделей, да.
Что касается сериализованных данных, то не вижу особых проблем — если всё делать аккуратно, ссылки в «наборах» прекрасно заменяются.
Но за ссылку на утилиту — спасибо, интересная штука, надо будет попробовать.
В сохранённом дампе базы данных WordPress ищем все вхождения mysite.local и заменяем на mysite.ru. Можно это сделать в любом нормальном текстовом редакторе (например, Notepad++). После замены аккуратно сохраняем БД, не забывая о кодировке (в случае с более или менее современными версиями WordPress нужна кодировка UTF-8 без BOM).
На этот вопрос много-много лет назад ответили ребята из СПК, сделавшие
пиратскуюгениальную локализацию WarCraft 2.Другое дело, когда данные вводятся в достаточно свободной форме — тогда имеет смысл сообщать об ошибке (по возможности — не модально).
Но мы же говорим о разработке собственного ПО, а здесь именно на нас, как на разработчиков, ложится ответственность за удобство работы. Разумеется, всегда нужно исходить из конкретной задачи. В конце концов, это программа должна быть инструментом (удобным!) в руках пользователя, а не пользователь — инструментом (сам-себе-валидатором) в руках программы.
Даже если взять АРМ, которым пользуются в небольшой конторе, допустим, 8 человек. Допустим, сейчас это 8 опытных сотрудников, которые хорошо знают, что и куда вводить в формах — их можно строго не ограничивать. А если завтра на их место придут новые сотрудники, плохо знакомые с устоявшимися принципами ввода данных? Вот чтобы они дров не наломали, нужно внимательно следить за вводом, ограничивая возможность ввода некорректных данных.
PS. На эту тему (информирование пользователя об ошибках ввода) очень хорошо написано у Купера в «About Face» — рекомендую к прочтению всем, кто проектирует интерфейсы.
Что касается опасности, то тут как минимум два нюанса. Во-первых, чем «свободнее» ввод, тем строже должна быть валидация. Это само по себе не проблема. Во-вторых, при копировании вероятность ошибки оператора в ряде ситуаций повышается (в сравнении с ручным вводом). К примеру, оператор копирует в поле ввода число 11127634,44 — если оператор случайно не выделит первую или последнюю цифры при копировании, то шанс, что он заметит ошибку ниже, чем если бы он вбивал числа вручную, глядя из окна в окно.
PS. Повторюсь, всё зависит от конкретного случая, где-то копипаст необходим, но не везде.
В других случаях, да, без копипаста не обойтись, но, как я уже сказал, тогда нужна строгая валидация и зачистка.
Ну и нумпады есть далеко не у всех моделей, да.