Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
 Posted: Mon Sep 27, 2004 10:14 pm
Implementing new design
|
I spent today implementing a lot of the changes I made to the Design Documents last week. So far I'm up to date on the zMessage object, which changed more than I had expected.
The past few days have really reinforced the notion of doing a written design for a project this big. With zMUD, I never did a formal design...I just kept it all in my head. While that worked most of the time, eMobius is too big and complex for this. Writing down the various interfaces has helped me see things from an "outside" perspective.
Just changing property names is an example. When I'm just coding, I'll tend to use more jargon for a property name. It's only when I'm documenting that I realize something doesn't make a lot of sense, or is more verbose than it needs to be.
For example, in the Message object, I've changed the "DeliveryDate" to just "Date" and "MessageFlags" to just "Flags". Since these are objects, you typically would refer to the flags field with something like Msg.Flags, and doing Msg.MessageFlags was just redundant.
Other changes were more complicated. In the Design, I added the concept of a "Contact" object, since we know that eventually eMobius will be dealing with contacts like Outlook does. So, the Sender field of a Message object isn't just a plain text string...it's a Contact object. The Recpient of a message also isn't a simple string, but is a Collection of Contact objects.
Now, the trick is implementing this without making the end-user scripting a mess. For example, making the Sender a Contact object is fine, but then how to you easily assign this field in a script? Normally, you would have to do something like this:
| Code: |
Contact = createobject("Zeus.zContact")
Contact.Name = "Zugg"
Contact.Address = "zugg@zuggsoft.com"
Message.Sender = Contact |
but that is really messy and verbose. So, I added some features to the scripting components to handle nested object calls. So now you can do this:
| Code: |
Message.Sender.Name = "Zugg"
Message.Sender.Address = "zugg@zuggsoft.com" |
which is how you'd expect it to work.
I even did something to make it even easier. The Contact object has a property called "Text" which returns both the name and email address in the RFC 2822 format: "Name <address>". By using this and implementing "default" properties for the objects, you can also now do this:
| Code: |
| Message.Sender = "Zugg <zugg@zuggsoft.com>" |
While I'm working on this kind of stuff, I also want to make Collections a bit easier to work with. For example, the Recipients, CCList, and BCCList fields are all Collections of Contact objects. To add a new contact to the Recipients list, you'd have to use the Recipients.Add( Contact) syntax, which means that once again you need to create a Contact object. What I'd like to add is some sort of syntax like this:
| Code: |
| Message.Recipients = "Zugg <zugg@zuggsoft.com>|Chiara <chiara@zuggsoft.com>" |
and have it automatically create a collection of two contact objects. But I still need to think about this and figure out how to implement it. There needs to be a way to specify a "item delimiter", like the | character, for each collection. And then the collection needs to know what type of object to create by default, and the object initialization needs to be able to take a string value like the Contact object can.
If I can make this kind of Collection creation more generic like this, then we'll have another really useful feature in eMobius to make scripting a lot easier.
While I was working on all of this, I ran into a couple more COM memory errors. Fortunately, thanks to the Cleanup idea that Raven and others proposed, I was able to track down a Delphi list object that I was using that was not set up to handle COM object references. Once I fixed that and added it to my cleanup routines, then the COM errors went away again.
The more I work on this, the more stable it gets and the easier it gets to work on. So, I think I'm going in the right direction now, even though it's going a bit more slowly.
Unfortunately, there is no way I'm going to have a release before my relatives visit in October, so I can't give you and ETA for the beta version yet. As usual, I'll release it when it's ready. |
|
