2NetFly
-
Господа, вы видимо не так меня поняли. Перечитайте дискуссию.
Каков был вопрос:
Почему бы сразу не описывать конфигурационный файл в формате кэша?
Я так понял, что формат кэша - это внутренняя структура языка. Я ответил, что это не позволит использовать одни и те же конфигурационные файлы для систем, написанных на разных языках. В то же время, использование языконезависимого формата (ini, xml или какого-либо другого) не несет таких ограничений. Я не пытался сравнить ini и xml и не утверждал, что для конфигурационных файлов какой-то из этих форматов предпочтительнее. Я утверждал только то, что хранение конфига в структуре языка - это не лучшее решение.
Каков был вопрос:
Почему бы сразу не описывать конфигурационный файл в формате кэша?
Я так понял, что формат кэша - это внутренняя структура языка. Я ответил, что это не позволит использовать одни и те же конфигурационные файлы для систем, написанных на разных языках. В то же время, использование языконезависимого формата (ini, xml или какого-либо другого) не несет таких ограничений. Я не пытался сравнить ini и xml и не утверждал, что для конфигурационных файлов какой-то из этих форматов предпочтительнее. Я утверждал только то, что хранение конфига в структуре языка - это не лучшее решение.
Макс
Старожил PHPClub
Фанат
ты понимаешь конфиг как один/два файла с настройками.
Но есть такие framework-и (например Prado - недавний победитель Zend). Где на каждый компонент свой XML-файл.
Под компонентами там подразумеваются такие классы как
TCheckbox , TImage, THyperLink и т.д.
В стандартном фреймворке их около 20.
А значит надо делать парсинг 10-20 xml-файлов при каждом запросе юзера.
Такое кеширование необязательно, но один из путей оптимизации скрипта.
Вопрсы типа "Зачем писать такие framework-и? Зачем их использовать" - это не ко мне.
ты понимаешь конфиг как один/два файла с настройками.
Но есть такие framework-и (например Prado - недавний победитель Zend). Где на каждый компонент свой XML-файл.
Под компонентами там подразумеваются такие классы как
TCheckbox , TImage, THyperLink и т.д.
В стандартном фреймворке их около 20.
А значит надо делать парсинг 10-20 xml-файлов при каждом запросе юзера.
Такое кеширование необязательно, но один из путей оптимизации скрипта.
Вопрсы типа "Зачем писать такие framework-и? Зачем их использовать" - это не ко мне.
2NetFly
-
Я бы не сказал, что это время совсем мизироное. Прибавь к парсингу открытие конфигурационного файла, считывание его содержимого и получишь неоправданные затраты, ради устранения которых стоит провести нехитрую оптимизацию.
Но это не все. Представь себе ситуацию, когда ты вносишь изменение в конфиг работающей системы и допускаешь ошибку. Без использования кэширования система тут же падает. С использование кэширования новый конфиг будет закэширован только в том случае, если он не будет содержать ошибок (синтаксических).
Макс
Старожил PHPClub
ini не хуже XML.
XML удобно использовать, когда нужно хранить дерево параметров.
ini позволяет лишь 2 уровня вложенности. Либо можно придумывать свой парсер для ini который бы обрабатывал параметры типа :
Код:
[form]
field.login = text
filed.login.validator = check_login
...wrapper
Guest
SiMM
>Почему бы сразу не описывать конфигурационный файл в формате кэша?
ИМХО это очевидно, кому нет, обосную:
1) Формат конфига будь то .ini или .xml более удобочитаемый
2) Для XML конфига можно сделать валидацию ( DTD, XML схема ), как вы будете валидировать захардкоденый кеш?
3) Есть разработчик некоего фреймворка, маппера, etc. а есть его пользователь, программист который используетт его в своем проекте. Зачем ему вообще знать о каком-то кеше? Это относится к реализации. Конечно если вы пишете нечто, которым планируете пользоваться единолично, этот пункт к вам не относится
4) Аргумент 2NetFly по поводу межязыковой переносимости
>Почему бы сразу не описывать конфигурационный файл в формате кэша?
ИМХО это очевидно, кому нет, обосную:
1) Формат конфига будь то .ini или .xml более удобочитаемый
2) Для XML конфига можно сделать валидацию ( DTD, XML схема ), как вы будете валидировать захардкоденый кеш?
3) Есть разработчик некоего фреймворка, маппера, etc. а есть его пользователь, программист который используетт его в своем проекте. Зачем ему вообще знать о каком-то кеше? Это относится к реализации. Конечно если вы пишете нечто, которым планируете пользоваться единолично, этот пункт к вам не относится
4) Аргумент 2NetFly по поводу межязыковой переносимости
SiMM
Новичок
Вот собственно и пришли к тому, что нужно знать, зачем этот конфиг нужен - говорить же безапелляционно, что xml/ini/php лучше (особенно аргументируя это модностью), не рассматривая среды применения - нет никакого смысла. Если речь идёт о настройке скрипта (логин/пароль к базе и другая мелочёвка) - то вполне можно использовать php.
Макс
Вопрос не в том, зачем писать такие фреймворки. А в том - сколько их в реальности?
Спасибо за пример случая, когда без кэширования конфигов (которые, на самом деле, есть часьи скриптов). И что дальше?
Если Автомобиль БелАЗ имеет грузоподьемность сто тонн то моя легковушка обязана иметь столько же?
Может быть, воздержаться от маргинальных примеров?
Вопрос не в том, зачем писать такие фреймворки. А в том - сколько их в реальности?
Спасибо за пример случая, когда без кэширования конфигов (которые, на самом деле, есть часьи скриптов). И что дальше?
Если Автомобиль БелАЗ имеет грузоподьемность сто тонн то моя легковушка обязана иметь столько же?
Может быть, воздержаться от маргинальных примеров?
Макс
Старожил PHPClub
Дело даже не в количестве а в их известности.
Prado и упоминаемый выше Propel - это очень известные разработки и когда ПХП5 появится на хостингах, они будут использоваться немалым количеством программеров.
Prado и упоминаемый выше Propel - это очень известные разработки и когда ПХП5 появится на хостингах, они будут использоваться немалым количеством программеров.
нет, но будет круто, если этот БелАЗ будет развивать такую же скорость как и твоя легковушка