BorlandTalk.com Forum Index BorlandTalk.com
Borland discussion newsgroups
 
Archives   FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Non DB related OPF

 
Post new topic   Reply to topic    BorlandTalk.com Forum Index -> Delphi OO design
View previous topic :: View next topic  
Author Message
J. França
Guest





PostPosted: Thu Feb 12, 2004 1:30 pm    Post subject: Non DB related OPF Reply with quote



I'm trying to design a OPF, but it is not intended to represent a database.
It must store my program options, window positions, plugin options.
I’m using a tree-like structure where each node is associated with its
storage.
The program must create objects from storage when they are needed.

But I have a problem with this:
- Some nodes are lists where subnodes (objects) can be added and removed
by users.
- There are links between objects: Objects “B” and “C” can be using
object “A”.
- User must not delete “A” because it is used by “B” and “C”, even if
“B” and “C” are not currently in use.

When objects are pre-created, even if “A” does not know anything about
“B” or “C”, they can add themselves to a list of “A” users, and I can
test if “A” is in use.
But, how can I do this without creating the whole list objects?

Back to top
Bryan Crotaz
Guest





PostPosted: Thu Feb 12, 2004 1:59 pm    Post subject: Re: Non DB related OPF Reply with quote



"J. França" <jfranca123 (AT) netscape (DOT) net> wrote

Quote:
I'm trying to design a OPF, but it is not intended to represent a
database.


OPFs aren't designed to represent databases - they are designed to store
objects in some form - could be XML, registry, ini files, blobs, anything!

Quote:
But I have a problem with this:
- Some nodes are lists where subnodes (objects) can be added and removed
by users.
- There are links between objects: Objects “B” and “C” can be using
object “A”.
- User must not delete “A” because it is used by “B” and “C”, even if
“B” and “C” are not currently in use.


I would recommend Bold for this job - it has all this built in and can load
and save to xml.
If you can't afford the upgrade, you'll need some sort of MayDelete method
which raises an exception in Delete if MayDelete returns false. Then have a
generic MayDelete which checks a metadata flag to see if a link is a
composite (ie delete prohibited if link is populated), then returns false if
the link has a count of at least 1.

Quote:
When objects are pre-created, even if “A” does not know anything about
“B” or “C”, they can add themselves to a list of “A” users, and I can
test if “A” is in use.
But, how can I do this without creating the whole list objects?

You'll need bi-directional links between objects, so when you add A to B, B
automatically gets added to A.

Bryan



Back to top
Marc Rohloff
Guest





PostPosted: Thu Feb 12, 2004 3:16 pm    Post subject: Re: Non DB related OPF Reply with quote



=?windows-1252?Q?=22J=2E_Fran=E7a=22?= wrote on Thu, 12 Feb 2004
09:30:15 -0400 ...

Quote:
I'm trying to design a OPF, but it is not intended to represent a database.
It must store my program options, window positions, plugin options.
I=3Fm using a tree-like structure where each node is associated with its
storage.
The program must create objects from storage when they are needed.

What type of storage are you planning on using?

Regardless I think you can design it much like any other OPF. If you
want to link objects then you will need to assign unique IDs and store
references with your objects.

Are you expecting a finite, predetermined number of classes or do you
expect users to be able to define their own ad-hoc?

Marc Rohloff

Back to top
J. França
Guest





PostPosted: Fri Feb 13, 2004 5:26 am    Post subject: Re: Non DB related OPF Reply with quote

Quote:
I would recommend Bold for this job - it has all this built in and can load
and save to xml.
If you can't afford the upgrade, you'll need some sort of MayDelete method
which raises an exception in Delete if MayDelete returns false. Then have a
generic MayDelete which checks a metadata flag to see if a link is a
composite (ie delete prohibited if link is populated), then returns false if
the link has a count of at least 1.

The MayDelete can be the answer...


Now to implement it is other isue...
My application must use multiple storage for objects, the tree isn't
fully known at design time. Some nodes can be lists of files on disk
and I cannot add metadata to them, but may be I can associate it in
other storage (a node with the list of links?).

Quote:

When objects are pre-created, even if “A” does not know anything about
“B” or “C”, they can add themselves to a list of “A” users, and I can
test if “A” is in use.
But, how can I do this without creating the whole list objects?


You'll need bi-directional links between objects, so when you add A to B, B
automatically gets added to A.

I can do the link, but in some cases I cannot save the data in my
originaly intended storage. Data must be stored in more than one place.
Perhaps I must use the storage with this data (an xml node) as the
main one, linking to files that store the subnodes:

<list Id=”Styles” Files=”.Config*.css”>
<node Id=”Style1”>
<user Id=”/outputs/Renderer1”/>
<user Id=”/outputs/Renderer2”/>
</node>
</list>

If I try to delete .ConfigStyle1.css I will find it is in use even if
Renderer1 and Renderer2 are not in memory now.

Quote:

Bryan

Thanks,

Jacinto



Back to top
J. França
Guest





PostPosted: Fri Feb 13, 2004 5:50 am    Post subject: Re: Non DB related OPF Reply with quote

Quote:
I'm trying to design a OPF, but it is not intended to represent a database.
It must store my program options, window positions, plugin options.
I=3Fm using a tree-like structure where each node is associated with its
storage.
The program must create objects from storage when they are needed.


What type of storage are you planning on using?

I'm trying to use multiple storage.

The main node may be an xml file, but some nodes can be lists of files.
Some of them other xmls. I think to use even dlls as nodes
(PlugIns with node classes).

Quote:
Regardless I think you can design it much like any other OPF. If you
want to link objects then you will need to assign unique IDs and store
references with your objects.

For a deep tree-like structure were some subnodes are out of my control,

I cannot assign a unique ID to each item. I was thinking to use a local
ID with an added path as a unique ID.

Quote:
Are you expecting a finite, predetermined number of classes or do you
expect users to be able to define their own ad-hoc?

I’m expecting multiple classes living in PlugIns.


Quote:
Marc Rohloff

Thanks,
Jacinto França


Back to top
Bryan Crotaz
Guest





PostPosted: Sat Feb 14, 2004 9:00 pm    Post subject: Re: Non DB related OPF Reply with quote

I do this with a plugin object (thus can be in a dll) which is responsible
for its own storage, and exposes IStreamable (remember to use Istream, not
TStream). It is responsible for monitoring storage for changes, usually via
singleton plugins (eg a singleton to monitor the registry) and reloading its
subnodes itself. I then use Subject-Observer to notify other parts of the
app of those changes.

Bryan


Back to top
J. França
Guest





PostPosted: Mon Feb 16, 2004 1:28 pm    Post subject: Re: Non DB related OPF Reply with quote


Bryan Crotaz wrote:
Quote:
I do this with a plugin object (thus can be in a dll) which is responsible
for its own storage, and exposes IStreamable (remember to use Istream, not
TStream). It is responsible for monitoring storage for changes, usually via
singleton plugins (eg a singleton to monitor the registry) and reloading its
subnodes itself. I then use Subject-Observer to notify other parts of the
app of those changes.

I have a node object to represent each PlugIn, but the exe is who store

the objects created from it. I was not using a IStream, the storage
just loads and stores the INode, writing its attributes and elements. I
did not think about external changes in storage... may be I must do.
The PlugIn itself is represented as a node whose subnodes are the
classes it exports, one of their attributes is the factory node (its
path) where they must belong.

My observable implementation is a litle strange:
My IObserver.DocChanged is a method that fits the Dispatch method,
so if I need different messages I can write message handlers like
TComponent subclasses do (My class must be not a TComponent subclass to
do so):
procedure IObserver.DocChanged = Dispatch;
procedure CmDestroy(var Msg: TCmDestroy); message cm_Destroy;
procedure CmAttributeChanged(var Msg: TCmAttributeChanged); message
cm_AttributeChanged;

Quote:
Bryan

Jacinto



Back to top
Display posts from previous:   
Post new topic   Reply to topic    BorlandTalk.com Forum Index -> Delphi OO design All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2006 phpBB Group
SEO toolkit © 2004-2006 webmedic.