20 Feb
2003
20 Feb
'03
2:36 p.m.
Hi Masashi,
I am currently developing a new Smalltalk Wiki implementation
(http://scgwiki.iam.unibe.ch:8080/SCG/520) and I am planning to use
SIXX to store my large tree-structures to xml. It seems to me the
perfect solution, because it can handle circular references and it
dialect independent.
My first attempt was to dump everything out into a XML file using the
following code from your tutorial:
sws := SixxWriteStream newFileNamed: 'root.xml'.
sws nextPut: wikiRootNode.
sws close.
The XML file looks fine, but unfortunately the XML parser is not able
to read that file again. The problem seems to be the huge binary data
(images, pdf) that is stored within ByteArray's.
I think storing binary-data to XML is not a good idea anyway, so I want
them to be put in special external files. The only thing to change - at
least I think so - is my Resource class, that contains this binary
data. So it should only dump the filename of the binary data and not
the data itself. To archive this goal, I wrote something similar to:
Resource>>sixxContentOn: aStream indent: level context: dictionary
| filename |
filename := self generateUniqueFilename.
self dumpToBinaryFile: filename.
super sixxContentOn: aStream ident: level context: dictionary
But how do I prevent SIXX from saving the binary data again, without
hardcoding the other i-vars? How do I archive the loading of the binary
data?
Could you give me some hints?
Thanks a lot for your help
Lukas
--
Lukas Renggli
http://renggli.freezope.org
20 Feb
20 Feb
3:06 p.m.
Am Donnerstag, 20.02.03 um 14:36 Uhr schrieb Lukas Renggli:
Hi Masashi,
I am currently developing a new Smalltalk Wiki implementation
(http://scgwiki.iam.unibe.ch:8080/SCG/520) and I am planning to use
SIXX to store my large tree-structures to xml. It seems to me the
perfect solution, because it can handle circular references and it
dialect independent.
My first attempt was to dump everything out into a XML file using the
following code from your tutorial:
sws := SixxWriteStream newFileNamed: 'root.xml'.
sws nextPut: wikiRootNode.
sws close.
The XML file looks fine, but unfortunately the XML parser is not able
to read that file again. The problem seems to be the huge binary data
(images, pdf) that is stored within ByteArray's.
I think storing binary-data to XML is not a good idea anyway, so I
want them to be put in special external files.
Hi Lukas and Masashi,
I really like to be able to store binary data in the xml-file very much
(I wasn't aware of that functionality of SmaCC),
so at least please keep it for me (and certainly fix it if necessary and
possible :-), as I want to make heavy use out of it in the near future.
Thanks,
Markus
The only thing to change - at least I think so - is my
Resource class,
that contains this binary data. So it should only dump the filename of
the binary data and not the data itself. To archive this goal, I wrote
something similar to:
Resource>>sixxContentOn: aStream indent: level context: dictionary
| filename |
filename := self generateUniqueFilename.
self dumpToBinaryFile: filename.
super sixxContentOn: aStream ident: level context: dictionary
But how do I prevent SIXX from saving the binary data again, without
hardcoding the other i-vars? How do I archive the loading of the
binary data?
Could you give me some hints?
Thanks a lot for your help
Lukas
--
Lukas Renggli
http://renggli.freezope.org
22 Feb
22 Feb
2:54 p.m.
Hi Lukas,
----- Original Message -----
I am currently developing a new Smalltalk Wiki
implementation
(http://scgwiki.iam.unibe.ch:8080/SCG/520) and I am planning to use
SIXX to store my large tree-structures to xml. It seems to me the
perfect solution, because it can handle circular references and it
dialect independent.
Great!
But how do I prevent SIXX from saving the binary data
again, without
hardcoding the other i-vars? How do I archive the loading of the binary
data?
I feel it is best to explain in code. So I attached the sample.
The sample is Squeak file-in format but you can read it by text editor.
Basically, in #sixxContentOn:indent:context:,
you can delegate the writing process to some of the children (inst-vars)
by using #sixxOn:name:indent:context:.
Resource>>sixxContentOn:indent:context:
| id newLevel fileStr |
"Write ID to XML instead of binary data"
newLevel := level + 1.
aStream cr.
id := self generateID.
id sixxOn: aStream name: 'resourceID' indent: newLevel context: dictionary.
"Write some other inst vars (optional)"
self name sixxOn: aStream name: 'name' indent: newLevel context:
dictionary.
"Dump actual data to file"
[fileStr := FileStream forceNewFileNamed: id.
fileStr nextPutAll: binaryData asArray printString. "just a sample - you
should use binary mode"]
ensure: [fileStr close.]
For the reading, you can override #sixxInstVarNamed:put:
Resource >>sixxInstVarNamed:put:
instVarName = 'resourceID' ifTrue: [ | fileStr |
[fileStr := FileStream readOnlyFileNamed: aValue.
self binaryData: (Array readFrom: fileStr contents) asByteArray]
ensure: [fileStr close.].
^self.
].
instVarName = 'name' ifTrue: [^self name: aValue].
There are other "hook" methods in SIXX for the more efficient
serialization/deserialization.
But I think the sample code fits your purpose.
I hope it helps. Please feel free to ask me, if you have some questions.
I'm looking forward to SmallWiki!
---
[:masashi | ^umezawa]
3:28 p.m.
Hi Markus and Lukas,
Hi Lukas and Masashi,
I really like to be able to store binary data in the xml-file very much
(I wasn't aware of that functionality of SmaCC),
so at least please keep it for me (and certainly fix it if necessary and
possible :-), as I want to make heavy use out of it in the near future.
Currently SIXX serializes binary data in a rather naive format
like this:
<sixx.object sixx.id="0" sixx.type="ByteArray" >#( 1 2 3 4
5 )</sixx.object>
It is sufficient for small data. But of course it is not so well if the data
is big.
The best solution I think is to zip the data and write it in base64 format.
Actually, in the SixxMorphMemento example (included in SIXX for Squeak -
maybe you are using SIXX for VW?), I use the method. (It is also a sample
of not adding 'sixx*' methods to existing classes, but ignore this aspect).
In the sample, very complex object (morph) is stored in XML.
But its downside is portability. There is no standard way in current
Smalltalks to make the binary data zipped (or base64).
So if you use this solution, your code will not run in other Smalltalks.
(like my SixxMorphMemento example).
But if you really have needs to do it in a portable manner, you can
add some indirect layer to achieve this by writing wrapper classes.
Cheers,
---
[:masashi | ^umezawa]
23 Feb
23 Feb
7:06 p.m.
Hi Masashi,
I feel it is best to explain in code. So I attached
the sample.
The sample is Squeak file-in format but you can read it by text editor.
Thanks a lot for the sample-code! It helped me a lot to finish
implementing the storage within a few minutes. SIXX does work perfectly
now, even with very big trees and several megabytes of binary data.
I'm looking forward to SmallWiki!
There will be a first public version soon, but there are still some
things that have to be finished and cleaned up before.
Cheers
Lukas
--
Lukas Renggli
http://renggli.freezope.org
7727
days inactive
7730
days old
4 comments
3 participants
participants (3)
-
Lukas Renggli -
Markus Gälli -
Masashi Umezawa