My favourite feature of the Wrapper Classes I keep going on about is the ready access they can give to any given class's related sub-classes.
For example, let's say you have an object based on the Customer class and you want to find all their Invoices. Wouldn't it be nice to write code like this in a WQO agent:
Dim customer As Customer, invoice As Invoice Set customer = New Customer(web.document) If customer.Invoices.Count > 0 Then Set invoice = customer.Invoices.getFirst() While Not invoice Is Nothing 'Do what you like here Set invoice = customer.Invoices.getNext() Wend End If
When you start using code like this in your day-to-day LotusScripting that's when it all starts to gel and there's no going back.
Imagine also that you wanted to know how many other invoices the customer for any given invoice has. You can do it like this:
Print "This invoice's customer has " + Cstr(invoice.Customer.Invoices.Count - 1) + " other invoices"
Adding Collection Properties
But how do we add this "Invoices" property? Easy. Just do something like this in the Invoice class:
Class Customer as DocumentWrapper Private Invoices_ As InvoiceCollection Private Factory_ As InvoiceFactory Property Get Invoices As InvoiceCollection 'lazy load the invoices! If Invoices_ Is Nothing Then Set Factory_ = new InvoiceFactory() Set Invoices_ = Factory_.GetInvoicesForCustomer(Me) End If Invoices = Invoices_ End Property End Class
Noticed we've defined a class-level InvoiceCollection and InvoiceFactory (we need to do this so they stay in scope). We then "lazy load" them the InvoiceCollection when it's first requested.
Here we're only going one level of sub-class deep. But you could go as many levels deep as you needed.
In the example above I've called a method called GetInvoicesForCustomer(). How this works depends on how your data is structured. Maybe the invoices are child documents of the Customer. Maybe they're just tied together by an "id" field. Either way, it doesn't really matter.