Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Сохранение списка

Страницы: 1 2 >
Stenfit © (2010-08-31 17:15:00)
есть список (наследник TList) записей типа TAttr.

PAttr = ^TAttr; TAttr = packed record Name: Str; Val : Variant; end;

Как грамотно сохранить его в stream. Пока что способов, кроме как использовать TWriter не знаю.

RWolf (2010-09-01 17:40:00) [1]

> Stenfit (31.08.10 21:48) [8]
> Не будет ли громоздким использование xml?

gzip-сжатие перед отправкой, как вариант.

Плохиш (2010-09-01 16:37:00) [2]

> Stenfit (31.08.10 21:48) [8]
>
> Уточню. Есть клиент и сервер (взаимодействуют через сокеты).
> Вместе с запросом, посылаемым клиентом серверу, необходимо
> передавать ряд параметров (для каждого запроса индивидуальны).
>

Я бы всё-таки посоветовал почитать про WebService. Может потом и велосипеда изобретать не придётся.

Медвежонок Пятачок (2010-09-01 11:08:00) [3]
я с ней в итоге и работал как с обычной хмл структурой перед тем как грузить из нее датасет.
работали бы просто с хмл - не было бы проблем вообще.

фрейм получил рутовый узел своей структуры.
очередной контрол нашел свой узел - загрузил из него данные. не нашел - остался бы пустым.
а по окею сохранил бы свои данные в предназначенный ему узел, создав его если его еще нет.

с датасетом такое возможно только через промежуточные манипуляции ибо в открытом датасете филдефсы не создашь, а в неоткрытом не видно какие поля вообще есть.

sniknik (2010-09-01 10:50:00) [4]
> если ссылаться на особенности стиля, то я могу сказать, что можно заточиться не на имена полей датасета а на их индексы и тоже получить облом.
> датасет то загрузится, а там дрова.
ну а я про что? собственно сам формат не дает никаких преимуществ (как бы это не рекламировали), он может только быть более или менее к чемуто конкретному, остальное делается программированием....
а для обмена данными (к вопросу об универсальности) в любом случае важны данные, а не то в каком формате они приходят (если этот формат не исковеркан конечно, какими нибудь самодельными парсерами). и на самом деле (посмотрел свой код) чаще всего при работе с хмл эмулирую стиль работы рекордсета, т.е. вместо
> ищем то, что ожидаем найти в внутри через selectsinglenode.
> найденное не нил? читаем валуе.
> найденное нил? значит просто нету значения.
делаю
ищем то, что ожидаем найти внутри (не важно как, и что, бывает нод бывает атрибут, бывает через поиск нода, а бывает перебором чилдов у родительского (одноименные списки)). разница дальше
найденное нил? вызываем ексепт об отсутствии поля, а значит и необходимых данных.
если допускаются дефаулты то вместо ексепта берется такое значение.

т.е. повторяю то, что при работе с рекордсетотом само делается. и смысл в этом есть... - получить адекватную ошибку при отсутствии данных, и желательно на этапе разработки программы, а не в процессе эксплуатации.

> но у каждой ук набор атрибутов свой персональный.
т.е. вы при явной "напрашиваемости" "не жесткой" структуры выбрали "жосткую". молодцы. к формату эта проблема отношения не имеет.

> вот вам и прелести "жоской" структуры
это "прелести" стиля программирования, и того, что при вероятной смене обменной структуры вы работали с ней как с неизменной. (в [25] разве не очевидно, что разницы нет?) работали бы аналогично как с xml привыкли и нет проблем.

Медвежонок Пятачок (2010-09-01 09:54:00) [5]
программировали мы как-то пифы. для рахных инвест компаний.
нужно было хранить атрибуты одних и тех же клиентов, но у каждой ук набор атрибутов свой персональный.
решили юзать блоб и сериализированные в нем датасеты.
для порождения новой записи сделали справочник с эталонной структурой полей.
породили много записей на основе его.
затем потребовалось изменить перечень атрибутов.
изменили справочник, изменили фреймы редактирования.
все снова работает.

кроме того, что ранее порожденные записи перестали редактироваться.
грузиться то они грузятся, но после этого новый фрейм ожидает что в датасете есть новые поля, а их там нет.
вот вам и капец.

пришлось перед открытием датасета работать с блобом как с простым xml документом и проверять наличие нужных полей (создавать их средствами простого хмл) и уже потом делати опен.

вот вам и прелести "жоской" структуры

Медвежонок Пятачок (2010-09-01 09:35:00) [6]
косяки с цифрами это просто потому что стиль программирования такой.
я давно не парюсь сам и не парю партнеров когда мне нудно обменяться с ними числовыми данными в строках.
написана один раз и на всю жизнь библиотечная функция
try_to_double(const Avalue : string) : double;
она вынет дабл из практически любой строки с любыит разделителями и постфиксами валюты.

если ссылаться на особенности стиля, то я могу сказать, что можно заточиться не на имена полей датасета а на их индексы и тоже получить облом.
датасет то загрузится, а там дрова.

sniknik (2010-09-01 02:01:00) [7]
> ты тоже либо оперируешь либо именами полей, либо жестко повязан индексами массива при инсертрекорд.
а почему нет самого простого, и самого нормального варианта? обращения к объектам полей. раз уж структура создана в дизайне то они обязательно будут, и никаких повторно используемых для обращений имен.

> Только там это не столь фатальные последствия повлечет.
только вчера разбирались с "проблемой" в хмл изменили даже не структуру, а данные, на одной стороне выровняли "для удобства чтения" формат чисел (нули после запятой, пробелы до, так чтобы были "столбики"), на другой стороне его прочитать не смогли... не знаю почему, ни к той ни к другой стороне не отношусь. просто выяснял в чем причина, партнерское ПО перестало работать.
не столь фатально конечно, как если бы прочитать смогли, но цифры бы исказили и не заметили, но все же. это же цифры! какая разница сколько там нулей после запятой? (и надо ли говорить что в "жесткой" структуре подобное невозможно)

> /*хотя это конечно не критично, когда пишешь софт исключительно для своей младшей сестры*/
на самом деле больше всего проблем именно с крупными компаниями, в которых твердо, до фанатизма уверены в универсальности/превосходстве xml-я для всего и вся и над чем угодно.
пример самого паршивого протокола на хмл приводил уже, и обсуждали на форуме, это МТС, с которым приходится работать.

> делаем лоад. загрузится? несомненно.
да ну? ни разу не сталкивался с не загружаемыми вариантами? :) посмотри на xml формируемый cds/adodataset для примера, загрузи их мелкософтским "домом". и т.д.
или ты считаешь что все работают "одним форматом"? ну ну.

> Может.
> Только там это не столь фатальные последствия повлечет.

> допустим пришла совсем иная структура на сервер.
> делаем лоад. загрузится? несомненно.
> ищем то, что ожидаем найти в внутри через selectsinglenode.
> найденное не нил? читаем валуе.
> найденное нил? значит просто нету значения.

теперь допустим прошел датасет в иной структуре на сервер
делаем лоад. загрузится? несомненно (с учетом одного формата, так же как и xml).
ищем то, что ожидаем найти в внутри через faindfield
найденное не нил? читаем валуе.
найденное нил? значит просто нету значения.

в чем разница? ты не описываешь "прелести" формата ты "воспеваешь" стиль работы. применимый к чему угодно. и при чем тут тогда xml???

хотя небольшая разница есть, из-за жесткой табличной структуры, faindfield придется один раз вызывать, и раз нету то нету, а для хмл для каждого нода где возможно/ожидаем найти поле.

Германн (2010-09-01 01:17:00) [8]

> Только там это не столь фатальные последствия повлечет.

А это уже от автора программы зависит фатальные или не фатальные.

P.S.
В "жесткости структуре" есть свои несомненные плюсы. Как в Паскале. Заставляют разработчиков быть ответственными и не плодить разные версии структур "по ходу дела".
/*хотя это конечно не критично, когда пишешь софт исключительно для своей младшей сестры*/
:)

Медвежонок Пятачок (2010-09-01 01:01:00) [9]
А для XML подобного быть не может?

Может.
Только там это не столь фатальные последствия повлечет.

допустим пришла совсем иная структура на сервер.
делаем лоад. загрузится? несомненно.
ищем то, что ожидаем найти в внутри через selectsinglenode.
найденное не нил? читаем валуе.
найденное нил? значит просто нету значения.

Германн (2010-09-01 00:54:00) [10]

> когда в сервере уже поелозили мышкой и изменили структуру
> полей датасета, а клиенты обновилдись еще не все.
>

А для XML подобного быть не может?

Медвежонок Пятачок (2010-09-01 00:46:00) [11]
записывая свои данные в датасет, ты тоже либо оперируешь либо именами полей, либо жестко повязан индексами массива при инсертрекорд.

как и я указываю имена атрибутов в которые записываю данные.

но я не отвлекаюсь на создание блока информации с метаданными датасета.
а ты отвлекаешься.
вот и вся разница.
у меня меньше кода.

я даже не упоминаю о версионности. когда в сервере уже поелозили мышкой и изменили структуру полей датасета, а клиенты обновилдись еще не все.

/*хотя это конечно не критично когда пишешь софт исключительно для своей младшей сестры*/

sniknik (2010-09-01 00:13:00) [12]
это не фокус, это нормальная работа.
не согласен тогда покажи как без внесения структуры(метаданных) в xml что-то вносишь. (действия аналогичны, отвергнутым действиям "мышкой", т.е. тоже фокус. в общем запиши данные не указывая имена/типы полей/атрибутов, местоположение (кто чей чилд). чисто данные)

Медвежонок Пятачок (2010-09-01 00:05:00) [13]
структура легко добавляется в дизайне "мышкой".

ну е-маё. а без фокусов можно?
а то ведь я тоже могу отделаться единственной строкой

xdoc.load('somefile.xml');

sniknik (2010-09-01 00:02:00) [14]
> достаточно привести каждому свой пример кода для рекорда из вопроса и сравнить объем кодирования.
именно кода?
пример -

ADataSet.CreateDataSet; ADataSet.InsertRecord([CustNoEdit.Text, CoNameEdit.Text, AddrEdit.Text, Null, Null, Null, Null, Null, Null, DiscountEdit.Text]); aDataSet.SaveToFile('Пример.xml', pfXML);

структура легко добавляется в дизайне "мышкой".

Медвежонок Пятачок (2010-08-31 23:53:00) [15]
гы. на этом месте как правило повисает длительная пауза перед съездом дискуссии в иное русло
:)

Медвежонок Пятачок (2010-08-31 23:49:00) [16]
хотя к чему эти споры?
достаточно привести каждому свой пример кода для рекорда из вопроса и сравнить объем кодирования.

все будет видно наглядно. очень наглядно.

Медвежонок Пятачок (2010-08-31 23:46:00) [17]
а если еще и структура не совсем "таблично-квадратная", то с датасетом вообще приплыли. сделать конечно можно, но опять же ручная возня как и в случае с тридером и трайтером, только еще больше.

Медвежонок Пятачок (2010-08-31 23:43:00) [18]
ну то есть как я и говорил.
с датасетом сначала программно возишься с филдефсами и только потом адденд/пост

с xml же сразу формируешь структуру которая нужна.

к тому же на другом конце (сервере или клиенте) приняв этот хмл можно его же использовать в своих корыстных целях. Напримерв процессе обработки создавать доп узлы и атрибуты куда записывать промежуточные резултаты или вообще ведя в нем же протокол обработки.

в случае же датасета - фик. ибо структура жесткая.

так что xml рулит однозначно.

sniknik (2010-08-31 23:37:00) [19]
> голый же xml - взял и сразу пиши туда все что душе угодно.
xml не голый... его уже кто то составил не так ли? вместе со структурой/метаданными, т.е. побарабанил пальцами. с рекордсетом(без уточнений "племени") аналогично, дадут готовый файл, откроешь, и будет сразу все вместе с метаданными/данными, и пиши туда все что душе угодно. а вот если с 0 то и там и там придется "побарабанить".

структура есть в обоих случаях, значит ее нужно "вбить". само собой, не бывает. в xml это только "размазано" делается в процессе, а не в начале.

Медвежонок Пятачок (2010-08-31 23:06:00) [20]
cds?
И в чем прикол.
сначала побарабанить пальцами и создать метеданные, и только потом приступить к заполнению.
то же самое с адодатасетом.

голый же xml - взял и сразу пиши туда все что душе угодно.

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »