Комментарии 93
Спасибо за статью :) А то я думал что я один такой "псих" на хабре, который верит что Delphi еще что-то может
да нет, дельфийцев много. наверное, боятся выделиться, а то заминусуют к чертям =)
щас кто-нить прибежит, начнет рассказывать про то, что Delphi умерла давно и не следовало ей рождаться =)
щас кто-нить прибежит, начнет рассказывать про то, что Delphi умерла давно и не следовало ей рождаться =)
А ведь были времена когда C++ на нас смотрели свысока, а мы им показывали самую удобную среду разработки и огромное количество "реально" полезных программ. А сейчас.. даже немножко стыдно, за то что изучаю Delphi.
Ох Borland как они нас кинули...
Ох Borland как они нас кинули...
Ну, программы-то никуда не исчезли. чего только стоят такие монстры как TheBat, TotalCommander и FruityLoops.
Сейчас Delphi - все та же удобная среда для разработки. Почему нет?
Сейчас Delphi - все та же удобная среда для разработки. Почему нет?
Без паковщиков программы на делфи вскрываются с потрохами. Взять тот же DeDe, который даже формочки и кнопки покажет с кодом. Это нормально?
Делфи генерит мегаогромные файлы со всяким гамном, которое никогда нигде никто не использует. Это нормально?
И вообще синтаксис делфи взят из паскаля студенческого языка программирования. Это нормально? :)
Какбэ, конечно, ну и фиг с ними, у каждого свой путь в жизни. Но называть делфи профессиональной средой увольте.
Делфи генерит мегаогромные файлы со всяким гамном, которое никогда нигде никто не использует. Это нормально?
И вообще синтаксис делфи взят из паскаля студенческого языка программирования. Это нормально? :)
Какбэ, конечно, ну и фиг с ними, у каждого свой путь в жизни. Но называть делфи профессиональной средой увольте.
посмотрите ссылку в комментарии ниже
>>Без паковщиков программы на делфи вскрываются с потрохами. Взять тот же DeDe, который даже формочки и кнопки покажет с кодом. Это нормально?
Да, это нормально. И не просто нормально, а отлично, т.к. позволяет с легкостью, при умении, расширять программы.
>>Делфи генерит мегаогромные файлы со всяким гамном, которое никогда нигде никто не использует. Это нормально?
То, что ты что-то не используешь - не значит, что это "гамно". Я использую, например, и очень часто. Также поступают и мои знакомые. "Гамно" - это C#, который вообще без огромной кучи другого "гомна" работать не будет.
>>И вообще синтаксис делфи взят из паскаля — студенческого языка программирования. Это нормально? :)
ЭТО ОТЛИЧНО!!! В этом и есть один из плюсов! Во всяком случае, для меня. Будь синтаксис другим, скорее всего не остановился бы, после С++, на Delphi.
>>Но называть делфи профессиональной средой — увольте.
Delphi - это язык программирования. Профессиональная среда - BDS 2006-2007, которая намного профессиональнее многих других IDE.
Всегда улыбаюсь, когда читаю такие коменты - люди, не зная нихрена о предмете обсуждения, пытаются что-то доказывать. Для информации, на одном из наследников языка Паскаль, написана операционка полноценная (Оберон), на Delphi легко можно писать драйвера и системный софт, а в прикладном софте даже рядом, по удобству, скорости разработке и поддержке, никто не стоит.
Да, это нормально. И не просто нормально, а отлично, т.к. позволяет с легкостью, при умении, расширять программы.
>>Делфи генерит мегаогромные файлы со всяким гамном, которое никогда нигде никто не использует. Это нормально?
То, что ты что-то не используешь - не значит, что это "гамно". Я использую, например, и очень часто. Также поступают и мои знакомые. "Гамно" - это C#, который вообще без огромной кучи другого "гомна" работать не будет.
>>И вообще синтаксис делфи взят из паскаля — студенческого языка программирования. Это нормально? :)
ЭТО ОТЛИЧНО!!! В этом и есть один из плюсов! Во всяком случае, для меня. Будь синтаксис другим, скорее всего не остановился бы, после С++, на Delphi.
>>Но называть делфи профессиональной средой — увольте.
Delphi - это язык программирования. Профессиональная среда - BDS 2006-2007, которая намного профессиональнее многих других IDE.
Всегда улыбаюсь, когда читаю такие коменты - люди, не зная нихрена о предмете обсуждения, пытаются что-то доказывать. Для информации, на одном из наследников языка Паскаль, написана операционка полноценная (Оберон), на Delphi легко можно писать драйвера и системный софт, а в прикладном софте даже рядом, по удобству, скорости разработке и поддержке, никто не стоит.
по поводу п. 1
Да, это нормально. И не просто нормально, а отлично, т.к. позволяет с легкостью, при умении, расширять программы.
Если бы человек хотел, чтобы его программу расширяли, он бы опубликовал ее открыто. Такая незащищенность недостаток компилятора Делфи.
Я знаю несколько успешных компаний с населенностью от 100 человек, у которых ERP написана на VBA в Excel. Да, оно работает, но это не нормально. Так же как и драйвера, написанные на Дельфи.
Я не менее часто улыбыюсь, когда люди не зная других людей делают о них выводы.
Успехов вам в ваших начинаниях!
Да, это нормально. И не просто нормально, а отлично, т.к. позволяет с легкостью, при умении, расширять программы.
Если бы человек хотел, чтобы его программу расширяли, он бы опубликовал ее открыто. Такая незащищенность недостаток компилятора Делфи.
Я знаю несколько успешных компаний с населенностью от 100 человек, у которых ERP написана на VBA в Excel. Да, оно работает, но это не нормально. Так же как и драйвера, написанные на Дельфи.
Я не менее часто улыбыюсь, когда люди не зная других людей делают о них выводы.
Успехов вам в ваших начинаниях!
Мдя... Выводы мои подтвердились:
>>Если бы человек хотел, чтобы его программу расширяли, он бы опубликовал ее открыто. Такая незащищенность — недостаток компилятора Делфи.
Имелось в виду, что сам разработчик сможет, при помощи RTTI, легко расширять программу. При чем тут защищенность??? Для защиты программного кода используются другие методы, а не компиляторы ;).
>>Я знаю несколько успешных компаний с населенностью от 100 человек, у которых ERP написана на VBA в Excel. Да, оно работает, но это не нормально. Так же как и драйвера, написанные на Дельфи.
Бред. Ненормально - говорить такие утверждений. Пример - что "нормальнее", написать программу на пару недель и пару десятков лет пользоваться (VBA + Excel) или написать программу на пару десятков лет, потом содержать целый отдел, чтобы поддерживать эту "конструкцию" в рабочем состоянии (C++)? Драйвера на Delphi - это не "не нормально". Зависит от задач.
>>Я не менее часто улыбыюсь, когда люди не зная других людей делают о них выводы.
Ну мои выводы подтвердились - вы ничего не знаете о Delphi, а тем более о внутреннем устройстве компилятора или IDE BDS. Вам в голову вдолбили, что "Delphi это отстой", вы и рады на каждом углу так орать, а в действительности понятия не имеете об огромных плюсам Delphi. Пора расти, а то так и будет "в каждой дырке затычкой"...
>>Если бы человек хотел, чтобы его программу расширяли, он бы опубликовал ее открыто. Такая незащищенность — недостаток компилятора Делфи.
Имелось в виду, что сам разработчик сможет, при помощи RTTI, легко расширять программу. При чем тут защищенность??? Для защиты программного кода используются другие методы, а не компиляторы ;).
>>Я знаю несколько успешных компаний с населенностью от 100 человек, у которых ERP написана на VBA в Excel. Да, оно работает, но это не нормально. Так же как и драйвера, написанные на Дельфи.
Бред. Ненормально - говорить такие утверждений. Пример - что "нормальнее", написать программу на пару недель и пару десятков лет пользоваться (VBA + Excel) или написать программу на пару десятков лет, потом содержать целый отдел, чтобы поддерживать эту "конструкцию" в рабочем состоянии (C++)? Драйвера на Delphi - это не "не нормально". Зависит от задач.
>>Я не менее часто улыбыюсь, когда люди не зная других людей делают о них выводы.
Ну мои выводы подтвердились - вы ничего не знаете о Delphi, а тем более о внутреннем устройстве компилятора или IDE BDS. Вам в голову вдолбили, что "Delphi это отстой", вы и рады на каждом углу так орать, а в действительности понятия не имеете об огромных плюсам Delphi. Пора расти, а то так и будет "в каждой дырке затычкой"...
http://delphi.wikia.com/wiki/Good_Qualit…
разве после посещения этой страницы за Delphi может быть стыдно?
разве после посещения этой страницы за Delphi может быть стыдно?
Да мне за среду разработки стыдно! (Я до сих пор стараюсь использовать Delphi 7 где только можно)
Я всегда восхищался дизайном среды, удобно, практично, супер... А теперь.. тебе BDS 2005-2007 ничего не напоминает? ОНИ ВСЕ СЛИЗАЛИ С Visual Studio? Обьясни мне, зачем отказываться от своих "гениальных" разработок и следовать моде?
Я всегда восхищался дизайном среды, удобно, практично, супер... А теперь.. тебе BDS 2005-2007 ничего не напоминает? ОНИ ВСЕ СЛИЗАЛИ С Visual Studio? Обьясни мне, зачем отказываться от своих "гениальных" разработок и следовать моде?
удивлен. что нету замечательных программ PicturesToExe, PixBuilder Studio и WinNavigator (он правда стар уже) замечательной компании wnsoft - www.wnsoft.com
А я, не найдя хорошего XML-компонента, как-то написал свой простенький XML-подобный язык Multilevel (что-то вроде многоуровневого ini-файла).
Кстати: спасибо за подсказку, как работать с published.
Кстати: спасибо за подсказку, как работать с published.
В Lazarus данная фича делается парой кликов мыши.
XMLDoc и XMLIntf, насколько я помню, есть с D7. А по поводу Lazarus - в Delphi тоже можно сделать в пару кликов, только будет менее универсально, как и в Lazarus. Lazarus-у еще ОЧЕНЬ далеко до Delphi 7, не говоря уже о BDS2006-2007.
ну рассказали бы хоть. я то я зря этот класс написал, получается?
Поищи по слову "Binding" ;)
XML Data Binding ?
Насколько я понял, это немножко другое. У меня это дело попроще.
Насколько я понял, это немножко другое. У меня это дело попроще.
Да, про XML Data Binding. Предназначено как-раз для того, чтобы сделать класс по образцу. И используется соответственно, в пару кликов.
Кстати, я не использую ни его, ни твой подход (который я уже где-то видел). Я пишу свой класс для каждой программы.
Кстати, я не использую ни его, ни твой подход (который я уже где-то видел). Я пишу свой класс для каждой программы.
Переходите уже на другую платформу. На .NET например. Там это 10 строк занимает, а у вас 100, это упадничество какое-то.
P.S. Я не в коем случае не хочу сказать, что Дельфи уже умерла, и не следовало ей рождаться, т.к. мне очень не хочется с кем то спорить в это чудесное утро.
P.S. Я не в коем случае не хочу сказать, что Дельфи уже умерла, и не следовало ей рождаться, т.к. мне очень не хочется с кем то спорить в это чудесное утро.
хотел в свое время, но как-то медленновато на нем все работает.
.NET прямой наследник Delphi
много строк тут занимает только класс-родитель, который делает за нас всю работу. с ним не надо возиться и переписывать.
а вот описание класса-наследника, действительно с нашим конфигов - получается очень мал. и менять мы его можем так, как нам захочется - ничего не сломается и все будет сохраняться/загружаться нормально.
а вот описание класса-наследника, действительно с нашим конфигов - получается очень мал. и менять мы его можем так, как нам захочется - ничего не сломается и все будет сохраняться/загружаться нормально.
Я по долгу службы изучаю .NET и скажу, что 10 строк там это все занимает только потому, что Микрософт за вас написала ну просто огромную кучу кода. 4000 классов о_О! И это только mscorelib! Сравните со 250 (приблизительно) в Delphi , и оцените насколько все грамотнее и лаконичнее (причем эти 250 включают в себя все компоненты). Ведь программы на Delphi пишутся с таким же успехом как и на .NET А то что структура int (обычное 32 битное число) имеет около 22 методов, вас не пугает о_О.
PS: Изучать надо язык на котором пишите.
PS: Изучать надо язык на котором пишите.
дельфи прекрасно работает с ini-файлами
или сабж немого о другом? :)
или сабж немого о другом? :)
можно прочитать и проверить.
о другом, конечно.
о другом, конечно.
т.е. не о конфиг-файлах?
об удобных и красивых конфиг-файлах. и о способе их автоматической загрузки и сохранения.
ну не знаю. на вкус и цвет как говорится...
по мне ini-файлы намного красивее xml-ек и удобнее в разборе как руками так и абсолютно любыми существующими инструментами.
повторюсь: я говорю о конфигах.
ИМХО удобный конфиг - это тот, который понятен и который легко правится.
по мне ini-файлы намного красивее xml-ек и удобнее в разборе как руками так и абсолютно любыми существующими инструментами.
повторюсь: я говорю о конфигах.
ИМХО удобный конфиг - это тот, который понятен и который легко правится.
вы видели конфиги JBoss ? конфиги на XML - величайшее зло (ИМХО).
нет, не видел. как и Вы не видели результатов отработки объекта моего класса.
ну залейте на pastebin :)
или лучше сначала попробуйте создать 2-3кб конфиг "по-вашему", а потом в консоли в vi(m) позанимайтесь его редактированием. если останетесь при мнении, что это удобно - показывайте публике.
или лучше сначала попробуйте создать 2-3кб конфиг "по-вашему", а потом в консоли в vi(m) позанимайтесь его редактированием. если останетесь при мнении, что это удобно - показывайте публике.
Гмм.. А в чём удобство xml-конфигов???
Для правки вручную - ужос-ужос.
Для парсинга... Довольно тяжёлая артилерия и так привлекается, а тут ещё и сверху такая портянка кода...
Не понимаю в чём смысл использования инструмента (xml) не по назначению.
Для правки вручную - ужос-ужос.
Для парсинга... Довольно тяжёлая артилерия и так привлекается, а тут ещё и сверху такая портянка кода...
Не понимаю в чём смысл использования инструмента (xml) не по назначению.
удобство примера в статье в том, что программисту, в случае изменения/удаления/добавления каких-либо свойств в настройки, не нужно переписывать/дописывать код, который эти настройки будет читать и сохранять.
Вы делаете такие программы, конфиги которых приходится редактировать вручную? - "ужос-ужос".
Расскажите нам, пожалуйста, в чем предназначение xml ?
Вы делаете такие программы, конфиги которых приходится редактировать вручную? - "ужос-ужос".
Расскажите нам, пожалуйста, в чем предназначение xml ?
1. Я не про пример, я про то, зачем хранить конфиги в xml? в чём удобство xml-конфигов?
2. Вы делаете такие программы, настройки которой кроме как с использованием этой же самой программы никак не изменить? Ужос-ужос. Ещё, поди, час менюшками для этого хлопать приходится? Ну-ну. Хотя нет :). Раз таки xml, значит ещё не всё потеряно :).
3. xml? в основном для обмена данными. Часто кроссплатформенного. Но конфигами кроме вашей программы никто другой не будет пользоваться. Зачем там xml?
2. Вы делаете такие программы, настройки которой кроме как с использованием этой же самой программы никак не изменить? Ужос-ужос. Ещё, поди, час менюшками для этого хлопать приходится? Ну-ну. Хотя нет :). Раз таки xml, значит ещё не всё потеряно :).
3. xml? в основном для обмена данными. Часто кроссплатформенного. Но конфигами кроме вашей программы никто другой не будет пользоваться. Зачем там xml?
XML гламурнее.
Не говоря о том, что сам по себе код довольно хреновый и дилетантский, он еще и некому не нужный. Вместо сабжа надо использовать стандартные механизмы сериализации объектов и не позориться.
ЗЫ
procedure TXMLClass.Initialize;
begin
end;
Нафиг пустой метод? Есть деректива abstract.
Префиксы а-ля венгерская нотация (oObject и iCount) не принято использовать в Delphi.
Если хочешь еще и много, то запость код на www.delphimaster.ru :)
ЗЫ
procedure TXMLClass.Initialize;
begin
end;
Нафиг пустой метод? Есть деректива abstract.
Префиксы а-ля венгерская нотация (oObject и iCount) не принято использовать в Delphi.
Если хочешь еще и много, то запость код на www.delphimaster.ru :)
о сериализации мы уже говорили в комментариях выше.
initialize - для использования в наследниках.
с префиксами привык, извините.
спасибо за отзыв.
initialize - для использования в наследниках.
с префиксами привык, извините.
спасибо за отзыв.
Кто сказал "надо использовать стандартные механизмы сериализации объектов"? Правильнее - "надо использовать то, что удобно и практично в данный момент". Если делать программу с десятком-другим настроек - да, можно и .ini использовать, и сериализацию. А если настроек 2-3к., то тут сериализация уже плохо, а .ini вообще не реально использовать. Зато .xml как-раз то, что надо - удобно, практично.
А вообще, я сторонник того, чтобы пользователь не мог добраться ручками до настроек программы.
А вообще, я сторонник того, чтобы пользователь не мог добраться ручками до настроек программы.
Ссылки почему-то не вставились :(.
Стандарт стилевого оформления исходного кода DELPHI
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=802
Сериализация объектов стандартными средствами Delphi
http://rsdn.ru/article/delphi/serialization.xml
Стандарт стилевого оформления исходного кода DELPHI
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=802
Сериализация объектов стандартными средствами Delphi
http://rsdn.ru/article/delphi/serialization.xml
>о сериализации мы уже говорили в комментариях выше.
Где? Я говорю о стандартной сериализации, которая используется самой средой и является естественной для Delphi.
>initialize - для использования в наследниках.
Я понимаю, так почему бы не сделать его абстрактным, коли реализации нет, а нужен он лишь для перекрытия в потомках?
А мое имхо, настройки проще хранить в ини, и не сериализовывать целые объекты. А на форум ты таки закинь исходник :)
Где? Я говорю о стандартной сериализации, которая используется самой средой и является естественной для Delphi.
>initialize - для использования в наследниках.
Я понимаю, так почему бы не сделать его абстрактным, коли реализации нет, а нужен он лишь для перекрытия в потомках?
А мое имхо, настройки проще хранить в ини, и не сериализовывать целые объекты. А на форум ты таки закинь исходник :)
Я не люблю форумы и не хочу никому ничего доказывать. если Вы считаете, что я не прав, используя такой код для хранения настроек, то я это уже понял, но не вижу причин перестать им пользоваться - он мне кажется удобным. если у Вас есть пример, как сделать то же самое, только лучше - почему бы его не написать, я им с большим удовольствием воспользуюсь. глядишь, и чему новому научусь - я знаю о том, что я не идеален и мой код тоже таким может и не быть и с удовольствием займусь его изменением в лучшую сторону.
Не, я на форум, только именно на этот, советую как раз для того, чтобы "чему новому научиться".
1) Конфиги лучше хранить в YAML формате
2) Конфиги зло, хотя в некоторых случаях действительно без них никак
3) Гибкие идеи не стоит искать среди интерпрайз решений
Это мое мнение, интересно будет послушать ваши возражения:)
2) Конфиги зло, хотя в некоторых случаях действительно без них никак
3) Гибкие идеи не стоит искать среди интерпрайз решений
Это мое мнение, интересно будет послушать ваши возражения:)
1. чем лучше?
2. согласен.
3. не понял.
2. согласен.
3. не понял.
1. YAML как раз создавался для таких целей. В общем здесь все написано - http://ru.wikipedia.org/wiki/YAML
2. -
3. Использование XML-х конфигов свойственно для java приложений, которые в большинстве своем громоздки и не блещут свежими идеями.
2. -
3. Использование XML-х конфигов свойственно для java приложений, которые в большинстве своем громоздки и не блещут свежими идеями.
1. для yaml нужно библиотеки какие-нить подключать сторонние. зачем, когда XML тоже с этим справляется. и уж тем более нативные майкрософтные библиотеки.
3. это же не значит то, что XML плох.
в чем плюс YAML перед XML ?
3. это же не значит то, что XML плох.
в чем плюс YAML перед XML ?
1. Для YAML уже написано куча библиотек под разные платформы. Если для вас скачать архив, распаковать и подключить компонент к проекту это препятствие перед тем что бы использовать лучшие решения.. чтож, пользуйтесь стандартными компонентами и бодрите себя мыслью, что они самые-самые....
3. А кто сказал что XML - плох? Плохим являеться решение использовать его для конфигурации каждого чиха в интрепрайз приложениях.
Про сравнение YAML и XML. Сравнивать их в общем смысле не корректно, ибо
"YAML — человекочитаемый формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования."
Т.е. XML язык разметки, а YAML нет, поэтому сравнивать их корректно только в нашем примере.
Ознакомиться с преимуществами YAML над XML в написании конфигурационных файлов можно на вики.
3. А кто сказал что XML - плох? Плохим являеться решение использовать его для конфигурации каждого чиха в интрепрайз приложениях.
Про сравнение YAML и XML. Сравнивать их в общем смысле не корректно, ибо
"YAML — человекочитаемый формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования."
Т.е. XML язык разметки, а YAML нет, поэтому сравнивать их корректно только в нашем примере.
Ознакомиться с преимуществами YAML над XML в написании конфигурационных файлов можно на вики.
1) "скачать архив, распаковать и подключить компонент к проекту это препятствие перед тем что бы использовать лучшие решения.. чтож, пользуйтесь стандартными компонентами и бодрите себя мыслью, что они самые-самые...." - Позвольте спросить, у вас много опыта в создании програмного обеспечения? (Своего, не для фирмы) Подключение любой сторонней библиотеки ведет к уйме проблем - изучение документации (если она есть), отладка и переотладка кода ибо сторонние библиотеки 99% имеют глюки которые приходиться учитывать и избегать. И все это ведет только к одному - трате драгоценного :) программистского времени. Намного проще и надежнее! написать код на стандартных компонентах. Этого же мнения придерживаются почти все ведущие специалисты.
3) Микрософт, Borland использует ХМЛ везде где только можно, и по вашему получается что они глупее вас? Зачем они выбирают "плохое" решение? Не смешите меня.
YAML и XML вообще не надо сравнивать ибо XML - универсален. Изучив его вы сможете применять его во множестве областей программирования, и вас всегда и везде поймут.
3) Микрософт, Borland использует ХМЛ везде где только можно, и по вашему получается что они глупее вас? Зачем они выбирают "плохое" решение? Не смешите меня.
YAML и XML вообще не надо сравнивать ибо XML - универсален. Изучив его вы сможете применять его во множестве областей программирования, и вас всегда и везде поймут.
1. Я пользуюсь свободными инструментами, а там любая более менее внятная библиотека является сторонней. А что касается изучения, то никогда не испытывал проблем с этим, проблем с отладкой и изучением никогда не испытывал, я не знаю откуда вы вообще это придумали. Мои коллеги и начальство тоже так считают
3. >Зачем они выбирают "плохое" решение? Не смешите меня
Это вы не смешите, интрепрайз на то он и интерпрайз - все должно быть стандартно и понятно любому идиоту, они никогда не ставили цели использовать что-то более менее современное. Их решения хороши с маркетинговой точки зрение, с технической они просто отвратительны.
"Изучив его вы сможете применять его во множестве областей программирования"
Ну я же не говорил, что "XML - не нужен", я его постоянно использую, однако хранить в нем конфиги это сверх избыточное решение, YAML штука специализированная и в общем-то примитивная по сравнению с XML, более того интуитивно понятная.
3. >Зачем они выбирают "плохое" решение? Не смешите меня
Это вы не смешите, интрепрайз на то он и интерпрайз - все должно быть стандартно и понятно любому идиоту, они никогда не ставили цели использовать что-то более менее современное. Их решения хороши с маркетинговой точки зрение, с технической они просто отвратительны.
"Изучив его вы сможете применять его во множестве областей программирования"
Ну я же не говорил, что "XML - не нужен", я его постоянно использую, однако хранить в нем конфиги это сверх избыточное решение, YAML штука специализированная и в общем-то примитивная по сравнению с XML, более того интуитивно понятная.
Да, стандартные решения тем и хороши, что они стандартные:
1. Если человеку разрешено копаться в файле настроек (что я считаю плохим признаком), то xml более удобен, т.к. его знают больше. При использовании YAML - его еще очень многим надо изучить, это не считая того, что очень многое в YAML зависит от непонятных (для новичка) пробелов и черточек. Короче - XML лучше, в данном случае.
2. Если файл настроек закрыт для ручного редактирования, то и разницы нет, для человека. А для программы XML проще - не надо использовать кучу лишнего хлама и чужих багов.
>>Если для вас скачать архив, распаковать и подключить компонент к проекту это препятствие перед тем что бы использовать лучшие решения..
Далеко не лучшие! К тому же, как уже написали ниже - скачать и установить не проблема, а вот изучение = потраченное время, часто (как в данном случае) впустую.
1. Если человеку разрешено копаться в файле настроек (что я считаю плохим признаком), то xml более удобен, т.к. его знают больше. При использовании YAML - его еще очень многим надо изучить, это не считая того, что очень многое в YAML зависит от непонятных (для новичка) пробелов и черточек. Короче - XML лучше, в данном случае.
2. Если файл настроек закрыт для ручного редактирования, то и разницы нет, для человека. А для программы XML проще - не надо использовать кучу лишнего хлама и чужих багов.
>>Если для вас скачать архив, распаковать и подключить компонент к проекту это препятствие перед тем что бы использовать лучшие решения..
Далеко не лучшие! К тому же, как уже написали ниже - скачать и установить не проблема, а вот изучение = потраченное время, часто (как в данном случае) впустую.
а у YAML есть сейчас порт для delphi?
Именно как delphi-модуля нету. Конечно есть реализации для .NET и еще куча разных реализаций:
- YAML C Libraries:
- libyaml # New Fast YAML (1.1)
- Syck # Old Fast YAML (1.0)
- PyYaml # YAML 1.1 Implementation
- JsYaml # JavaScript PyYaml port
- RbYaml # Ruby port of PyYaml
- JvYaml # Java port of PyYaml
- ocaml-syck # Syck bindings for OCaml
- Perl Modules:
- YAML # Pure Perl YAML Module
- YAML::XS # Binding to libyaml
- YAML::Syck # Binding to libsyck
- YAML::Tiny # A small YAML subset module
- PlYaml # Perl port of PyYaml
- YamlReference # Haskell 1.2 reference parser
- YPaste # Play with the Haskell 1.2 parser
- YAML C Libraries:
- libyaml # New Fast YAML (1.1)
- Syck # Old Fast YAML (1.0)
- PyYaml # YAML 1.1 Implementation
- JsYaml # JavaScript PyYaml port
- RbYaml # Ruby port of PyYaml
- JvYaml # Java port of PyYaml
- ocaml-syck # Syck bindings for OCaml
- Perl Modules:
- YAML # Pure Perl YAML Module
- YAML::XS # Binding to libyaml
- YAML::Syck # Binding to libsyck
- YAML::Tiny # A small YAML subset module
- PlYaml # Perl port of PyYaml
- YamlReference # Haskell 1.2 reference parser
- YPaste # Play with the Haskell 1.2 parser
я не читал коменты, не думаю что там в холи-варе что-то полезное есть, но вдруг howto именно там конечно
но идею не очень понял, может я туповатъ, а может автору незачет
точнее вообще не понял: имелся в виду подход, что класс будет сохранять свойства обьектов, которые ему подсовывают? или же мне надо дописывать в классе-наследнике каждое свойство?
надо было рядом с базовым классом положить и пример наследника что-ли
з.ы. а делфи рулит
но идею не очень понял, может я туповатъ, а может автору незачет
точнее вообще не понял: имелся в виду подход, что класс будет сохранять свойства обьектов, которые ему подсовывают? или же мне надо дописывать в классе-наследнике каждое свойство?
надо было рядом с базовым классом положить и пример наследника что-ли
з.ы. а делфи рулит
все published свойства объекта класса-наследника от класса, приведенного мной в статье будут им сохраняться и читаться.
ну если так до допустим
тогда в теории вроде сложные типы тоже можно сохранять? к примеру я хочу помнить настройки шрифта для неважно-чего; я должен в published добавить свойство MyFont, и перед сохранением настроек просто присвоить ему указатель на шрифт, настройки которого я хочу помнить? вроде в SaveClass попадаем, что свойство == класс определяем, но дальше
tkClass:
if Assigned(PropInfo^.GetProc) and Assigned(PropInfo^.SetProc) then
begin
LObject := GetObjectProp(oObject, PropInfo);
if LObject nil then
никогда не срабатывает
это бага или фича?
тогда в теории вроде сложные типы тоже можно сохранять? к примеру я хочу помнить настройки шрифта для неважно-чего; я должен в published добавить свойство MyFont, и перед сохранением настроек просто присвоить ему указатель на шрифт, настройки которого я хочу помнить? вроде в SaveClass попадаем, что свойство == класс определяем, но дальше
tkClass:
if Assigned(PropInfo^.GetProc) and Assigned(PropInfo^.SetProc) then
begin
LObject := GetObjectProp(oObject, PropInfo);
if LObject nil then
никогда не срабатывает
это бага или фича?
под настройки шрифта создайте отдельный класс на базе TPersistent.
TFontProperty = class(TPersistent)
и его опишите точно так же - published свойства этого объекта попадут внутрь.
а в своем классе определите property Font: TFontProperty.
объект, на который будет ссылаться Font, нужно будет создать и уничтожить.
TFontProperty = class(TPersistent)
и его опишите точно так же - published свойства этого объекта попадут внутрь.
а в своем классе определите property Font: TFontProperty.
объект, на который будет ссылаться Font, нужно будет создать и уничтожить.
небольшой пример - http://codepaste.ru/1068/
Решил опробовать модуль и получил ругань от 7 Дельфи
SetPropValue(Self, PropInfo^.Name, StrToInt(sValue));
SetPropValue(Self, PropInfo^.Name, StrToInt(sValue));
Почему то пост сам отправился без моего ведома. Пишу снова.
На строки
Шла ругань
После исправления на:
На строки
SetPropValue(Self, PropInfo, StrToInt(sValue));
Шла ругань
[Error] tlXMLClass.pas(79): Incompatible types: 'String' and 'PPropInfo'
После исправления на:
SetPropValue(Self, PropInfo^.Name, StrToInt(sValue))Все стало нормально.
Вы уверены, что в приведенном коде статьи ошибок нет?
silentroach
Все 3 моих коментария относяться к коду изложенному в вашем блоге, как оказалось он не соответсвует исходикам в статье.
Все 3 моих коментария относяться к коду изложенному в вашем блоге, как оказалось он не соответсвует исходикам в статье.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Конфиг-файлы в Delphi без проблем