Комментарии 25
XML используют в конфигах, чтобы не надо было пересобирать приложение и по новой деплоить его на сервер. Достаточно поменять две строчки в web.xml (любом другом конфиге) и все готово. Собственно, для этого используют нетолько XML конфиги, а, вообще, все конфиги на свете.
И еще не стоит забывать, что приложения отсылаются заказчику в виде откомпилированных модулей, поэтому иначе как через конфиги настроить он его не может.
Описанная проблема тоже как-то несовсем ясна. Любые два конфига объединяются элементарной операцией под названием ctrl-c+ctrl-v. :)
И еще не стоит забывать, что приложения отсылаются заказчику в виде откомпилированных модулей, поэтому иначе как через конфиги настроить он его не может.
Описанная проблема тоже как-то несовсем ясна. Любые два конфига объединяются элементарной операцией под названием ctrl-c+ctrl-v. :)
>XML используют в конфигах, чтобы не надо было пересобирать приложение и по новой деплоить его на сервер. Достаточно поменять две строчки в web.xml (любом другом конфиге) и все готово. Собственно, для этого используют нетолько XML конфиги, а, вообще, все конфиги на свете.
Конфиги используются для того, чтобы конфигурировать ;)
Про компиляцию — я не говорю, что надо отказаться от всего на свете и жёстко зашивать. Мелочь типа connection string-а и переопределение компонентов можно сделать в XML. Кроме того не все языки являются компилируемыми 8)
>Описанная проблема тоже как-то несовсем ясна. Любые два конфига объединяются элементарной операцией под названием ctrl-c+ctrl-v. :)
Это хреновые вариант обьединения, худшим вариантом является только тот вариант, когда обьединение вообще невозможно.
Конфиги используются для того, чтобы конфигурировать ;)
Про компиляцию — я не говорю, что надо отказаться от всего на свете и жёстко зашивать. Мелочь типа connection string-а и переопределение компонентов можно сделать в XML. Кроме того не все языки являются компилируемыми 8)
>Описанная проблема тоже как-то несовсем ясна. Любые два конфига объединяются элементарной операцией под названием ctrl-c+ctrl-v. :)
Это хреновые вариант обьединения, худшим вариантом является только тот вариант, когда обьединение вообще невозможно.
Прошу заметить, что XML вообще не язык программирования, а язык разметки структурированных данных, поэтому не стоит сравнивать теплое с мягким.
А в огороде бузина, а в Киеве дядька.
Вот именно. XML по большому счету нужен для хранения структурированных данных. А вы его обвиняете в отсутствии наследования и полиморфизма. Тогда уж и MySQL обвините что-ли.
Я XML не обвиняю. Я обвиняю людей, которые из XML делают недо-форматы, с которыми невозможно работать.
Что самое любопытное, так то что автор сказал что XML эт плохо, но при этом не сказал чем он его собирается заменять и почему. Ну а раз этого не сказано, то сие можно воспринимать только как демогогию.
читаем по диагонали? Заменять нормальным ЯП.
Я не читаю по диагонали. Потому что не объяснено каким образом это будет заменяться и как это будет работать. Если менять значения в коде, а затем производить компиляцию и запуск, то это чистой воды бред. К тому же мне сильно интересно как автор собирается из GUI менять значения. В случае XML все просто и удобно.
В моём случае большинство вещей просто не имеет смысл конфигурировать пользователю (как пример — web.xml файл). Но часть настроек несомненно нужно иметь в свободно-редактируемом файле (не факт, что это будет XML).
>К тому же мне сильно интересно как автор собирается из GUI менять значения.
Хороший вопрос. Видимо необходимо сереализовать (можно даже в xml) конфигурационные обьекты.
>К тому же мне сильно интересно как автор собирается из GUI менять значения.
Хороший вопрос. Видимо необходимо сереализовать (можно даже в xml) конфигурационные обьекты.
Вы ошибаетесь. Во первых объединить средствами xml можно если это заложено логикой приложения. К примеру interceptor'ы в struts 2. Во вторых вы пытаетесь объединить часть приложения которая является «отправной» точкой в вэб приложении. И на мой взгляд логично что создатели не заложили этого в функционал. Попробуйте немного абстрагироваться от конкретики и поразмышлять: «Как и зачем нужно наследовать настройки готового приложения?» Как мне кажется это глупо. А зачем вам это нужно?
Я привёл пример для чего мне этого нужно. Те же проблемы возникают у многих людей, например уже ранее упоминаемый мной NUXEO решил проблемму «динамического web.xml» тем, что начал использовать свой runtime engine.
Если у меня есть 10 приложений, в которых есть некоторая общая часть (в частности web.xml — общий набор сервлетов, фильтров и тп), то (имхо) естественно, что я пытаюсь выносить общие части в библиотеки. Что вы предложите мне в этом случае (кроме уже упомянутого copy-paste)?
Если у меня есть 10 приложений, в которых есть некоторая общая часть (в частности web.xml — общий набор сервлетов, фильтров и тп), то (имхо) естественно, что я пытаюсь выносить общие части в библиотеки. Что вы предложите мне в этом случае (кроме уже упомянутого copy-paste)?
Добро пожаловать в суровый мир J2EE =)
НЛО прилетело и опубликовало эту надпись здесь
Просто каждый инструмент существует для определённых задач, автор немного перепутал задачи.
Вы или не читали то, что я написал или прочитанное не поняли. Про полиморфизм и наследование — обьясните, что в этом смешного? Если это так смешно, почему в большинстве конфигурационных файлов это не сделано?
НЛО прилетело и опубликовало эту надпись здесь
>Но вы, наверное, хотели чего-то не того, а чтобы как-то оно само все поддерживало.
Я хочу чтобы так же как в любом ЯП я мог бы в любом конфигурационном файле использовать наследование и полиморфизм. В сегодняшнем мире этого нет в 99% конфигурационных файлов на XML.
А про то, что на чём угодно можно написать что угодно — я знаю.
Я хочу чтобы так же как в любом ЯП я мог бы в любом конфигурационном файле использовать наследование и полиморфизм. В сегодняшнем мире этого нет в 99% конфигурационных файлов на XML.
А про то, что на чём угодно можно написать что угодно — я знаю.
Процетирую сам себя (для особо ленивых читателей):
Вывод такой — как только у тебя появляется конфиг чуть более сложный, чем указание factory метода — сразу переноси конфигурацию из XML в нормальный ЯП (заменяя Schema-у на API) иначе будешь постоянно мучаться, РЕАЛИЗОВЫВАЯ ВСЕ СТАНДАРТНЫЕ ФИШКИ ЯЗЫКА ПРОГРАММИРОВАНИЯ в своём XML формате.
Вывод такой — как только у тебя появляется конфиг чуть более сложный, чем указание factory метода — сразу переноси конфигурацию из XML в нормальный ЯП (заменяя Schema-у на API) иначе будешь постоянно мучаться, РЕАЛИЗОВЫВАЯ ВСЕ СТАНДАРТНЫЕ ФИШКИ ЯЗЫКА ПРОГРАММИРОВАНИЯ в своём XML формате.
Ох уж эти пуристы… Каждому инструменту — свое применение!
Добро пожаловать в суровый мир хабра ;)
Функциональность приложения определяется бинарным кодом.
Политика применения приложения определяется конфигами.
И кто хочет от такого положения вещей отойти, то есть совместить политику с функциональностью — ССЗБ.
Политика применения приложения определяется конфигами.
И кто хочет от такого положения вещей отойти, то есть совместить политику с функциональностью — ССЗБ.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
конфиги: XML vs. API