[RE: [Re: [lazarus] How are we going to store component data?]]

[Baeseman, Cliff]

the dom model says you have to use base64 encodeing but that should not
really matter..

Cliff

-----Original Message-----
From: Michal Bukovjan [mailto:mbukovjan at netscape.net]
Sent: Wednesday, July 21, 1999 5:42 PM
To: lazarus at miraclec.com
Subject: Re: [RE: [Re: [lazarus] How are we going to store component
data?]]


Hi,

I'll try to straighten things up. 

"Baeseman, Cliff" <Cliff.Baeseman at greenheck.com> wrote:
> hmmm the dfm should be in xml format so that us or any other language
> wishing to use a lazarus dfm can do so without having to build a parser.
> Lazarus will interpret the xml file using a parser to generate the
necessary
> code .inc.
> 
> Cliff
> 
>

Yes, I agree.


> Michal Bukovjan wrote:
> > 
> > I think this is not much usable, because :
> > 
> > 1} The storage mechanism starts at TForm. This caused a lot of pain in
> > Delphi, because for compound components, it is highly preferable that
> > a TComponent class can remember its state.
> 
> I'm afraid you have me confused here. What pain is there in Delphi
> because of this????
> 
> What do you mean, 'preferable that a TComponent class can remember its
> state'? What state are you talking about?

There is no pain in Delphi now, because from Delphi (2?) up you can stream
out
just any component. But way back in Delphi 1, this was a major drawback.
</THEORY> I am talking about a persistent state of objects, which is a great
thing to have - it means that the object has easy and STANDARD way to
remeber
its attributes before it is destroyed and is able to retrieve them back when
it is created again. (See the awkward way how to accomplish this in COM,
various discussions on Delphi forums, etc.}.
<THEORY/>
As I understood, the CreateDesignForm is created by IDE to be compiled into
the project as a virtual procedure and later called from the constructor.
While this is sufficient for basic IDE RAD, the TForm is still a SPECIAL
case
and a more generic approach (Delphi-wise) is what should be in here.
 
> > 2} It is for design-time only. While this may be enough for RAD,
> 
> This is all it is good for. That is all it is used for in Delphi.
> 

Maybe you are right, I do not have the Delphi sources. How do you think they
copy components via clipboard? Anyway, that is NOT all it is used for by
Delphi programmers (me included), trust me. Consider how easily can be done
a
custom report design (for printing, by end-users) in Delphi applications ...

> > the Delphi system allows for much more flexible run-time behavior, you
> > can stream the component (and its children) to an arbitrary stream,
> > send over whatever you like {pipe, file, DCOM/CORBA connection, shared
> > memory) and make use of the component state in another instance, or
> > another app altogether. Not to mention storing component's state in a
> > database BLOB !
> 
> There is nothing that will prevent you from doing that. The data that is
> stored in the resource in a Delphi app is not modified by the runtime it
> is used read only. If you are doing any of the above it isn't because it
> is part of the basic RAD form design features of Delphi.

But the RAD in Delphi USES that mechanism. See component streaming support
in
TStream and its descendants, TFiler, TReader, TWriter objects. The .DFM file
is just a component hierarchy having its persistent state written into a
file.
So the Delphi IDE makes heavy use of these features, in fact it is build
upon
it.

> 
> > While the binary stream-out may not be the best solution (i.e. XML
> > might be better), I suggest we use some sort of streaming technique.
> 
> That would require additional files be delivered with the application,
> one for every form that you design for the program. This isn't something
> I want to do. When I build the application I just want to be able to
> deliver the executable and nothing else.

I think you can link that into the executable, which is a part done by
linker,
but I am not expert in this area, so you are probably right.

However, the streaming techniques on which is Linux build, simply fascinates
me. Through streams in XML format, you could even stream TForm or TGroupBox
or
whatever out of Lazarus to a WWW server, creating a WWW page !!!

>  
> > 3) Using the below system, reading of larger pixmaps, sound clips or
> > whatever binary data could be real fun :-(
> 
> Why?? I'm confused by your whole email.

How would you represent a bitmap or a sound clip in text? BASE-64 or
MIME-encoding? or these nice numbers Delphi shows when you open a .dfm?
Could
be fairly large, and I am not sure about compiling efficiency then.

Maybe we still don't understand each other, in which case I apologize and
beg
for further explanations.

Regards,

Mike


____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at
http://webmail.netscape.com.

_________________________________________________________________
     To unsubscribe: mail lazarus-request at miraclec.com with
                "unsubscribe" as the Subject
    archives at http://www.miraclec.com/list_archives/lazarus