I'm just curious in how many different ways the following concept could be
implemented. I have two in my head, thinking that opne might be better than the
other. I have done my best to avoid using coded examples in an effort to not
give any preconceptions.
I'm not necessarily looking for actual code, but rather pseudo code &
theoreticals (but I'm not going to deny actual code if you have it.)
Concept:
A sort of "Ad-Hoc" class. The class to be implemented as an ActiveX DLL that
would exhibit the following characteristics:
1) Dynamic Properties. In one instance (Obj1), I may need a property called
"Prop1", but in another (Obj2), it might be "Property1". Properties may need to
be added on the fly.
2) The class may or may not be "hard". "HUH?!" you say. Meaning that once the
property structure is set, it cannot be changed or added to. Let's say that Obj1
from the previous example is "hardened", but Obj2 isn't. If I assign a value to
the property "Property1" of Obj1, an error ocurrs. But, if I assign a value to
the property "Prop1" of Obj2, no error ocurrs, and I can retrieve the value
later. NO CHANGES to the object's structure should be allowed. For flexability,
could be an On/Off switch. Or, it can be set once and that's it.
3) Persistance. It must have a way to save it's state. May or may not be to
the hard drive. This includes both data and structure.
4) Serialization. Most good objects should do this.
5) Copy or clone method.
6) For a lack of a better term, Templating. Same as persistance, but structure
only. After the object is created, the structure is loaded and then optionaly
hardened.
7) Merge. Able to take the structure of one object and merge it (or the
properties) into another. For example, if I take Obj2 and merge it into Obj1
(assuming Obj1 isn't hardened), Obj1 would then have both "Prop1" and
"Property1" properties.
8) Data Overlay. As an addon to #7, optionaly include data as well as the
structure. Be able to indicate whose data over writes whose in the event that
common properties are found.
9) Simple. Above all else, it should be simple to use. Allow for the greatest amount of flexability in the least number of steps.
There's no prize. And like I said, no actual code is expected, I'm only looking for theoretical ideas. Although, if you want to spend the time trying to code something & would like ot share it, then by all means, be my guest. As for me, I already have worked out some ideas in my mind (I don't plan to post them for a little while to prevent preconceptions, but eventually, I will.)
For starters, it started out for fun, see if it could be done (I think it can). But then I started ti think about it a bit more, and I actually think I might have a use for it (haven't decided yet). That said, maybe if I walk you through the thought process I went through, you might be able to see what I was thinking.
It started w/ the object cloning thread else where. While going through it, I realized that I too have had prior needs to clone a data object, creating two distinct instances. At anyy rate, I was think how nice it would be to dynamically retrive properties, do a sort of for each, like you had mentioned. Then I started thinking about serializing and transfering the data from one copy to the other. As for the requirements.... no reason for them. Just didn't want to make it too easy.
VB Varients make this pretty easy. Simply hold an array of strings (property names), and array or varients (values), or one array of a UDT that holds both of the above. Then, Some functions for Adding properties, removing them again, setting values, getting values, hardening, cloning, and merging. Cloning and merging would utilize the first four functions, in a loop.
Actually, at some point I am going to have to write one of these in C++, for a database system I am working on. Essentially, you can add properties to the thing, but you also attach a query string to the property. When you attempt to read from the property the first time, it queries the database for the value, and gives it back. From then on, it just uses that value.
Originally posted by Edneeis So it's kind of like exploratory research, that's cool. That's the main reason I gave it a try.
Bingo. Sorry that didn't come out better.
At any rate...
This is exactly what I was talking about. Each of us knew to get from point A to point B. But took different routes to get there. Edneeis used a collection, UDT and PropBags to get there. Zaei suggested UDTs and arrays. On the other hand, I'm using XML document to hold everything. I'll post that in a minute, I'm finishing the demo.
Each has their own drawbacks, and their advantages. One may work in one situation, but necessarily in all situations.
Sometimes, I've seen people so dead set on doing it one way, and not open to other ideas. My goal for this was to promote some kind of discussion to show that there is more than one way to do the same thing. Edneeis had an elegant solution using the PropBag, I never would have though of that. Instead, I used XML, saving it to an XML file to persist my data.
Ah, ha! Took me a while... but here it is at last!
Here's my solution -- this is the one that's been running around in my brain all afternoon.
Took me awhile, but I got it.
One caveat: It uses MSXML (v2.0) so, to use it, you'll need to get MSXML from Microsoft.
You know, using strings, you could actually add properties to properties...:
Code:
PropThing.AddProperty("Prop1")
PropThing.AddProperty("Prop1.Sub-Prop1")
PropThing.SetProperty("Prop1.Sub-Prop1", 10)
PropThing.SetProperty("Prop2", 20) ' adds a property under the hood
Simple. Since you are simply storing the property name as a string, Prop1, and Prop1.Sub-Prop1 are two unrelated properties... ::shrug:: might be useful =).
Originally posted by Zaei You know, using strings, you could actually add properties to properties...:
Code:
PropThing.AddProperty("Prop1")
PropThing.AddProperty("Prop1.Sub-Prop1")
PropThing.SetProperty("Prop1.Sub-Prop1", 10)
PropThing.SetProperty("Prop2", 20) ' adds a property under the hood
Simple. Since you are simply storing the property name as a string, Prop1, and Prop1.Sub-Prop1 are two unrelated properties... ::shrug:: might be useful =).
Z.
You sure could.
BTW: I like the idea behind the C++ object you mentioned. My only concern about it would be trying to access several properties in a row. Won't there be a performance hit as each query is executed?
You would take a performance hit when FIRST accessing the property, but after that, the property would be cached, and would only go out to the database when ordered specifically to.
What I meant was, what if I need to access 12 properties. Will it make 12 trips to the DB getting each property? Or will it go once, getting all 12, the first time I access the first property.
' first time access, go to the database, and query
' with the query attached to "Prop1"
x = PropThing.GetProperty("Prop1")
' Second access, dont go to the DB, just return the cached property
x1 = PropThing.GetProperty("Prop1")
' First access, go to DB
x2 = PropThing.GetProperty("Prop2")
So the first time you try to access a property, it would go to the DB to get it. After that, it would use the saved value. So, if you accessed 12 properties in a row that had never been accessed before, it would go to the database 12 times. If you then accessed them 12 more times, it would give you abck the cached data, and not go to the database.
I like your XML idea Techgnome, it's like a really cool XML wrapper only better. Good job.
One thing you left off the set options on the properties so it can't hold objects right now. XML can handle serializing objects can't it? I really like how you let the XML take care of most of the difficult stuff, like I did with the collection but the XMLDOM can do more.
With the DB idea if all the properties are in the same table maybe it should get the whole table on the first property and cache all the properties at once so it makes less trips to the DB.
Well, the properties can be anywhere in the database, plus the object can have properties added at any time. Also, the database is really designed for fast access to unique fields, so I wouldnt be able to search for more then one property at once.
My main reason for going with XML was because it was easy to save to the HD (which is what I needed for my project) and load it back. My "linked list" class also uses the XML concept, but to an even greater degree by allowing attributes to be set. But I also liked your idea of propbags. Less overhead & you didn't use any additional items (such as the XML parser).
As far as serializing objects.... if you can get it to binary data, you can use the CDATA[ construct in XML to store the bytes.
Not really that difficult, but could be a pain since the developers of the MSXML object didn't make it easy (at least not as easy as setting an attribute or tag element.
He's got one up on us Edneeis, I didn't think about removing properties. I also like the idea of a Release method that essentially clears out the object.
One thing of note was the (De)Serialization. When deserializing, you write out each property in a name/value pair, but in the serializing, you only read in the first one. But then again, I had only asked for theoreticals.
The Put method writes out the entire array to disk in one go. For some reason when I tested the same with the Get method, it didint work, so i just did it in a loop.
Dynamic-Polymorphing Class Object Challenge
Reply With Quote
There are some great ideas in here....
