Dictionary vs multiple Properties

Is there a reason not to use a Dictionary (assigned to a Property) to replace a series of related Properties? This way I can group related global values, as though they’re in a folder of Properties (which we apparently don’t have in our arsenal). For instance, I can have a set of global properties related to the currently selected Customer, all found in a single Dictionary. Until yesterday, I hadn’t thought of using a Dictionary for that, and have been storing such values in a series of Properties in either the Session object or a WebPage object.

Before I continue with this way of storing global values, I’d like to know if there is a downside to this. It seems to offer me a better way of organizing global values.

Overhead, readability and ease of use later.

Overhead; accessing data in a dictionary has an overhead (takes more time).

Readability; “myObject.opacity” v.s. “myObject.lookup( kMyObjectPropertyOpacity, myObjectPropertyOpacityDefaultValue )”.

Ease of use later; to see what properties an object has type “myObject.” And press the tab key. With a dictionary you need to keep a separate list of constants (technically you don’t, but you’ll understand why you when you come back to the project 6~24 months later).

Both are bad solutions… because global variables are a bad solution. In 99% of all cases global variables are used to save the cost of passing around arguments to the objects using them.

When I’m talking about “global” variables in this case, I’m actually talking about Web app public Properties in the Session or WebPage object. I’m not talking about global Properties in a Module. Still a problem?

[quote=355779:@Sam Rowlands]Overhead, readability and ease of use later.

Overhead; accessing data in a dictionary has an overhead (takes more time).

Readability; “myObject.opacity” v.s. “myObject.lookup( kMyObjectPropertyOpacity, myObjectPropertyOpacityDefaultValue )”.

Ease of use later; to see what properties an object has type “myObject.” And press the tab key. With a dictionary you need to keep a separate list of constants (technically you don’t, but you’ll understand why you when you come back to the project 6~24 months later).[/quote]

I see what you mean, Sam. I’ll have to think more on this.

I frequently use a combination of computed property & xojo.core.dictionary. Mainly because I want readability and the ease of being able to convert the properties to and from a json string.

Have you considered creating a Customer class and putting your properties on it? With the class you’ll have a grouping of the properties that you can easily pass around as needed. You could even create a single property of type Customer on the Session if you needed things more global.

This sounds perfect. Thanks.

Ok, I’m try get my head around how to do this. Suppose I create a new Customer class and it has a public property ID, and I want to be able to access that globally. And to make it more globally accessible, I create a Session.Customer property of type Customer. It looks like I need to place something like this in Session.Open:

Dim a As New Customer Session.Customer = a

Is that correct?

Yes, that is the idea. Since you’re doing it in Session.Open you should use Self instead, I’d avoid using the same name, but that doesn’t really matter, and you can combine it to one line:

Self.CurrentCustomer = New Customer

[quote=355894:@Paul Lefebvre]Yes, that is the idea. Since you’re doing it in Session.Open you should use Self instead, I’d avoid using the same name, but that doesn’t really matter, and you can combine it to one line:

Self.CurrentCustomer = New Customer

Yes, I would have used Self instead of Session, but didn’t know I could combine all this in one line like you pointed out. Thanks.