Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
хммм. оригинальное решение ))) а про последствия Dreamweaver`a вы не думали!? )))) можете не отвечать )
Какие?
1. избыточность кода
2. наём дополнительных верстальщиков
3. невозможно стелать большой сайт (например интернет-магазин)
4. Допустим вы его всё таки сделали - представьте что будет если надо кое-что обновить на всех страницах
P.S. what means "Вопросы о синхронизации обновлений"? Какие вопросы ;-)
P.P.S. да, я ничуть не защищаю ваших программеров! но ваш выход из сиутации ни на секунду не лучше!
2. наём дополнительных верстальщиков
3. невозможно стелать большой сайт (например интернет-магазин)
4. Допустим вы его всё таки сделали - представьте что будет если надо кое-что обновить на всех страницах
P.S. what means "Вопросы о синхронизации обновлений"? Какие вопросы ;-)
P.P.S. да, я ничуть не защищаю ваших программеров! но ваш выход из сиутации ни на секунду не лучше!
Для одинакового кое чего на всех страницах есть автозамена и SSI. Хотя в современном мире и на коммерческих сайтах это извращение.
В Dreamweaver имеется система статических шаблонов, которая ускоряет разработку и поддержку сайтов. Изменения, применяемые к шаблону, автоматически после запроса программы применяются ко всем страницам, использующим его.
Избыточность кода и прочее проблемой не является, так как:
1. Верстальщиков у нас и так достаточно, они только вот целыми днями бодаются с «фичами» движка, вместо того чтобы делать сайты
2. Верстальщики достаточно грамотны, чтобы не делать сайт чисто на визуальном редакторе Дрима, кодирование в Блокноте - для многих реальность.
3. Macromedia уже давно позаботилась о вопросах множественной замены, диалог замены в Дриме - один из самых вменяемых среди всех редакторов. Если вообще отвлечься от визуальной составляющей, редактор HTML гениален и насыщен рабочими инструментами на пределе.
Впросы о синхронизации обновлений - это впросы, которые образуются, когда программеры дописывают костыли к движку и в срочном порядке заставлют верстал обновить движок. Еще - сайт выливается на testing-сервера, чтобы клиент принял изменения. Когда на сайте два движка (один в подпапке) - сами понимаете, потребное для этой операции внимание увеличивается вдвое (не перезалить конфиг, не перепутать, это движок-папа или движок в подпапке итд)
Избыточность кода и прочее проблемой не является, так как:
1. Верстальщиков у нас и так достаточно, они только вот целыми днями бодаются с «фичами» движка, вместо того чтобы делать сайты
2. Верстальщики достаточно грамотны, чтобы не делать сайт чисто на визуальном редакторе Дрима, кодирование в Блокноте - для многих реальность.
3. Macromedia уже давно позаботилась о вопросах множественной замены, диалог замены в Дриме - один из самых вменяемых среди всех редакторов. Если вообще отвлечься от визуальной составляющей, редактор HTML гениален и насыщен рабочими инструментами на пределе.
Впросы о синхронизации обновлений - это впросы, которые образуются, когда программеры дописывают костыли к движку и в срочном порядке заставлют верстал обновить движок. Еще - сайт выливается на testing-сервера, чтобы клиент принял изменения. Когда на сайте два движка (один в подпапке) - сами понимаете, потребное для этой операции внимание увеличивается вдвое (не перезалить конфиг, не перепутать, это движок-папа или движок в подпапке итд)
XML/XSL рулят.
И причем тут XML/XSL???
Вопрос в неправильной организации данных
А вся проблема решается доп таблицей "сайты" или "языковые версии" и привязками экземпляров приложений к той или иной версии.
А заливать копию движка это все-таки круто ;)
Вопрос в неправильной организации данных
А вся проблема решается доп таблицей "сайты" или "языковые версии" и привязками экземпляров приложений к той или иной версии.
А заливать копию движка это все-таки круто ;)
Я дела то о чем вы говорите. Если есть практические вопросы htaccess/php, обращайтесь.
Все правильно, уважаемый. Вопрос в неправильной организации данных.
Не для каждого сайта нужна база. Это во-первых.
XML/XSL платформы чудесно справляются с мультиязычностью. Это во-вторых.
Не для каждого сайта нужна база. Это во-первых.
XML/XSL платформы чудесно справляются с мультиязычностью. Это во-вторых.
Для каждого сайта отдельная база вовсе необязательна, более того, даже если сайты разместить на разных доменах. Достаточно ввести дополнительный уровень иерархии.
При помощи XML/XSL мы сможем отлично перевести интерфейсы управления приложениями, но не более, в прочем тоже самое мы сможем провернуть используя простой набор файлов с различными переводами. Я не утверждаю, что ваше решение чем-то может не устроить. Просто оно одно из многих решений.
Но давайте по-честному, в топике речь не шла о переводе интерфейсов :)
При помощи XML/XSL мы сможем отлично перевести интерфейсы управления приложениями, но не более, в прочем тоже самое мы сможем провернуть используя простой набор файлов с различными переводами. Я не утверждаю, что ваше решение чем-то может не устроить. Просто оно одно из многих решений.
Но давайте по-честному, в топике речь не шла о переводе интерфейсов :)
Да дело не только в интерфейсах. Не знаю как вы, а я реализовал уже довольно много сайтов, которые поддерживают 7-8 языков, на XML/XSL платформе. Весь контент был в XML-файлах, что позволило переводчикам работать чуть ли не из дома, при минимальном умении работы с текстовым редактором.
Трансформатору наплевать из какой папки тащить XML, а при грамотно настроеном кэше не возникает проблем с нагрузкой.
Трансформатору наплевать из какой папки тащить XML, а при грамотно настроеном кэше не возникает проблем с нагрузкой.
Насколько я вас понял, сначала предполагается какая-то одна отправная языковая версия, которая позднее клонируется с поправкой на локализацию. Так, или я ошибаюсь?
Если вы про работу с контентом, то да. Сайт создается на одном языке, затем переводится на другие. Это ясно.
Чтож, в любом случае наше обсуждение - это технологический взгляд на поставленную проблему, использовать те или иные технологии - это в большей степени решение системного аналитика, либо решение, принятое из кадровых соображений. Реализована ли выдача клиенту на XML или на шаблонизаторе типа Smarty, проблема лежит в содержании (Model), но не в форме (View), думаю, вы со мной согласитесь.
Автора же, вероятно, беспокоит в большей степени идеологическая составляющая :)
Автора же, вероятно, беспокоит в большей степени идеологическая составляющая :)
Можно и без перезаливки с помощью .htaccess перенаправить.
Но вообще странно, движок что, не умеет создавать страницы с определённым адресом?
Но вообще странно, движок что, не умеет создавать страницы с определённым адресом?
Программисты здесь - мастера отболтаться. Все работники, не рубящие в PHP, молча хавают, что они скажут. Беда именно в них. Менеджеры - отдельная сказка. Тоже беда, но уж они то реализацией, по крайней мере не занимаются. Все их ляпы в конечном итоге исправляются версталами и тестером. Вопрос только в сроке.
А, ну про ТЗ - обычно же начальство говорит «Пишите двиг». Прогеры грят: «Дайте ТЗ». Вот ТЗ. Делают, потом на сдаче формулируют: «Для реализации этой фичи мы ввели в движок специальную таблицу ** и класс ****. Этот подход позволяет создавать многоязычные сайты.» Ну кто из шефов, скажите, полезет проверять, позволяет он или нет? Как это сделать? Движок существуют в голом виде, без единой странички, ничего не откроешь в браузере, никаких доков, ничего абсолютно. Только заявления и заверения программистов. Просто очень смешно стало, когда версталы в присутсвии начальства спросили про многоязычную версию, программеры повиляли, ПРИЗНАЛИ, что нельзя, в итоге посовещавшись выдали «решение». Я рыдал...
Вам нужно открывать стартдаун, где будет текстареа, в которую вводишь чистый код и он форматируется в код, который делают ваши программисты ;)
пс
по-моему лучший выход сделать файлы
ru.inc
en.inc
примерно такого содержания
$submit="submit" - в en.inc
и
$submit="добавить" - в ru.inc
в верху индекса прописать че-то типо if $lang="" $lang="ru" include $lang.inc
и запрос к главной будет типа index.php?lang=$lang
по-моему самый простой выход ;)
пс
по-моему лучший выход сделать файлы
ru.inc
en.inc
примерно такого содержания
$submit="submit" - в en.inc
и
$submit="добавить" - в ru.inc
в верху индекса прописать че-то типо if $lang="" $lang="ru" include $lang.inc
и запрос к главной будет типа index.php?lang=$lang
по-моему самый простой выход ;)
Это значит переписывать движок. В прошлой серии блокбастера меня ко всяким переменным «со своими улучшениями» не пустили, нажаловавшись начальству на самоуправство. За участие спасибо
ну да разве что каждое слово заменять переменной) зато можно будет хоть 1000 языков вставлять в сайт) ну и запросы к бд в переменные вбить) в принципе дело 2-3х дней, да и любой работник сможет вбить слова в файлы переменных. Но ваши коддеры скажут, что они «умные» и от любого предложения откажутся, и все сделаю супер пупер неудобным ) Это я так понял по вашим рассказам)
Вообще мне, честно говоря, очень интересно читать ваши рассказы про чудо-коддеров, заседающих в вашем офисе) Хотя, судя по минусам, только мне одному. Обидно.
пс
Подумайте над стартдауном =D
пс
Подумайте над стартдауном =D
Да, кстати, окончание прошлой серии блокбастера потерялось в хабратумане . Краткое содержание: я серьезно улучшил движок, повысив скорость разработки сайта верстальщиками. Прогеры на меня нажаловались шефам, что я изуродовал их движок, что теперь всё не так и они не могут продолжать работать. Дело касалось на самом деле изменения 4 переменных и алгоритма их присвоения перед выводом страницы. Архитектуры движка, методик написания плагинов это не касалось. Тем не менее, начальство повелело «вернуть всё взад». В смысле лишние переменные убрать, четыре строчки превратить обратно в две. Что я и сделал - там, куда они пальцем ткнули, всё стало как прежде.
Как будто это единственное место, где что-то можно поменять! Новые изменения держатся уже неделю, ни один из ранимых программеров ничего пока не заметил. Планирую места дальнейшего перемещения моих улучшений в случае чего.
Как будто это единственное место, где что-то можно поменять! Новые изменения держатся уже неделю, ни один из ранимых программеров ничего пока не заметил. Планирую места дальнейшего перемещения моих улучшений в случае чего.
я серьезно улучшил движок, повысив скорость разработки сайта верстальщиками. рогеры на меня нажаловались шефам, что я изуродовал их движок, что теперь всё не так и они не могут продолжать работать.
Без предупреждения? Не будем вдаваться в тонкости, но если у вас есть предложение по улучшению чужого кода, то корректнее было бы обсудить с программистами эти изменения, обосновать эффективность. Или, что еще лучше, поговорить о желаемых критериях выдачи данных. Думаю, программисты согласились бы, и внесли бы осознанные изменения в движок.
Как будто это единственное место, где что-то можно поменять! Новые изменения держатся уже неделю, ни один из ранимых программеров ничего пока не заметил. Планирую места дальнейшего перемещения моих улучшений в случае чего.
А вот это чистейшей воды вредительство! У вас там команда или шайка мелких пакостников и ябед?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пц II. Программеры столкнулись с задачей из реального мира.