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

← →
Stenfit (2010-08-31 17:15) [0]

есть список (наследник TList) записей типа TAttr.

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

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

← →
Сергей М. © (2010-08-31 17:18) [1]

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

← →
Медвежонок Пятачок © (2010-08-31 17:29) [2]

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

плюсы:
не надо писать сериализацию, она уже есть (Load,LoadXML).
не надо писать десериализацию, она уже есть (save).
имеешь встроенные средства поиска и фильтрации (selectnodes,selectsinglenode).

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

← →
nik (2010-08-31 17:50) [3]

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

плюсы:
не надо писать сериализацию, она уже есть (LoadFromFile).
не надо писать десериализацию, она уже есть (SaveToFile).
имеешь встроенные средства поиска и фильтрации (findfirst,locate,filter).
...
имеешь стандартные способы отображения (dbgrid,dbedit,dbxxxx)
имеешь стандартные способы работы с базой при переходе на критические объемы...
и .тд.

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

← →
Сергей М. © (2010-08-31 17:58) [4]

> nik (31.08.10 17:50) [3]

ну коль скоро речь коснулась дельфийских data-aware-контролов, то почему не использовать TClientDataSet ?
Там тебе и сериализация готовая, там тебе и XML ..

← →
sniknik © (2010-08-31 19:02) [5]

> то почему не использовать TClientDataSet ?
не принципиально... я вот предпочитаю TADODataSet, но не настаиваю и не пихаю его всем как некоторые xml.
(а его назойливое рекламирование это + к тем вещам за что его не люблю. в общем то эту рекламу считаю основой из за которой пошли все последующие проблемы)

← →
Сергей М. © (2010-08-31 20:43) [6]

> sniknik © (31.08.10 19:02) [5]

Я собссно к тому что в CDS есть и готовая сериализация/десериализация и, если уж угодно, тот самй назойливый Хмыль, коль скоро приспичит поддаться уговорам)

← →
QAZ (2010-08-31 21:28) [7]

> освободи свой мозг и пальцы для более творческих задач.

а вы последние лет 5 не замечали что производительность компов растет
паралельно с падением быстродействия софта?

← →
Stenfit (2010-08-31 21:48) [8]

Уточню. Есть клиент и сервер (взаимодействуют через сокеты). Вместе с запросом, посылаемым клиентом серверу, необходимо передавать ряд параметров (для каждого запроса индивидуальны). Как в таком случае грамотно хранить и передавать параметры? Не будет ли громоздким использование xml? Если использовать xml, то как правильно передать его содержимое через сокет? ... TXMLDocument.SaveToStream и полученный стрим через сокет? Так?

← →
_Юрий (2010-08-31 22:01) [9]

> Stenfit (31.08.10 21:48) [8]

> Не будет ли громоздким использование xml?

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

← →
sniknik © (2010-08-31 22:02) [10]

> Я собссно к тому что в CDS есть и готовая сериализация/десериализация и, если уж угодно, тот самй назойливый Хмыль, коль скоро приспичит поддаться уговорам)
а я собссно к тому что в TADODataSet есть и готовая сериализация/десериализация и, если уж угодно, тот самй назойливый Хмыль, коль скоро приспичит поддаться уговорам)

← →
sniknik © (2010-08-31 22:11) [11]

> Как в таком случае грамотно хранить и передавать параметры?
все уже придумано до нас... возьми к примеру изучи протокол http там и запрос и параметры передаются, нужно больше данных чем в GET влазит? смотри POST, еще больше данных? смотри базы/клиент сервер/трехзвенки типа midas/soap, в общем по изучай то, что есть до изобретения своего велосипеда...

← →
Медвежонок Пятачок © (2010-08-31 23:06) [12]

cds?
И в чем прикол.
сначала побарабанить пальцами и создать метеданные, и только потом приступить к заполнению.
то же самое с адодатасетом.

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

← →
sniknik © (2010-08-31 23:37) [13]

> голый же xml - взял и сразу пиши туда все что душе угодно.
xml не голый... его уже кто то составил не так ли? вместе со структурой/метаданными, т.е. побарабанил пальцами. с рекордсетом(без уточнений "племени") аналогично, дадут готовый файл, откроешь, и будет сразу все вместе с метаданными/данными, и пиши туда все что душе угодно. а вот если с 0 то и там и там придется "побарабанить".

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

← →
Медвежонок Пятачок © (2010-08-31 23:43) [14]

ну то есть как я и говорил.
с датасетом сначала программно возишься с филдефсами и только потом адденд/пост

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

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

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

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

← →
Медвежонок Пятачок © (2010-08-31 23:46) [15]

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

← →
Медвежонок Пятачок © (2010-08-31 23:49) [16]

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

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

← →
Медвежонок Пятачок © (2010-08-31 23:53) [17]

гы. на этом месте как правило повисает длительная пауза перед съездом дискуссии в иное русло
:)

← →
sniknik © (2010-09-01 00:02) [18]

> достаточно привести каждому свой пример кода для рекорда из вопроса и сравнить объем кодирования.
именно кода?
пример -

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

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

← →
Медвежонок Пятачок © (2010-09-01 00:05) [19]

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

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

xdoc.load("somefile.xml");

← →
sniknik © (2010-09-01 00:13) [20]

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

← →
Медвежонок Пятачок © (2010-09-01 00:46) [21]

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

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

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

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

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

← →
Германн © (2010-09-01 00:54) [22]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

косяки с цифрами это просто потому что стиль программирования такой.
я давно не парюсь сам и не парю партнеров когда мне нудно обменяться с ними числовыми данными в строках.
написана один раз и на всю жизнь библиотечная функция
try_to_double(const Avalue : string) : double;
она вынет дабл из практически любой строки с любыит разделителями и постфиксами валюты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сохранение списка Найти похожие ветки