I am working on the architecture for the Exchange Web Service solution that I am building. As I indicated in my blog post, the OpenEdge AppServer will receive notifications of updates from Exchange.
Each notification will include an item that implements the interface IExchangeItem. CalendarItem is one such object.
The API will publish an event indicating that a CalendarItem has changed, and it will include the CalendarItem with it. The item has a number of methods, but once the item is published, it is switched to read-only mode. In other words, the item that is being received, cannot be changed - we need to preserve the state as it was when it came in from Exchange.
Among the things that a CalendarItem has is a set of invitees - people invited to the meeting. That set is an ordered list that could be anything from one to as many attendees as you like. I have several alternatives for storing the invitees:
I can encapsulate the temp-table in the IExchangeItem and provide a query object on the temp-table to allow the caller to iterate through the list of items. The problem is I have no way to prevent the caller from modifying the contents of the temp-table. I cannot stop them from deleting a row or adding in a new object.
The other thing about temp-tables as collections is the performance cost of creating and maintaining a query for each object that wants to maintain an iterating cursor through the collection.
Now I have to concede that given my Java and .NET experience, I am prejudiced toward supporting collections in the ABL. So it could be that I am thinking about this problem the wrong way, or there is some obvious change to the architecture that I am missing. If so, please feel free to point it out. I really am looking for opinions on this.
10.2B has variable-sized arrays .
/* do not specify an extent */
DEF VAR foo AS CHAR EXTENT NO-UNDO.
EXTENT(foo) = invitees:Count().
Julian
On 27 April 2010 20:28, Bruce Gruenbaum
I don't know how big the array is up front. I'm getting it as a set of elements in an XML document. I need the array to resize as I add.
Create a class to hold n (10, 20 whatever) numbers of invitees, and
create a new object when a limit is reached.
Julian
On 27 April 2010 21:07, Bruce Gruenbaum
Actually, that idea has some potential to it. I'd still have to provide some kind of iterator so that iterating through the whole collection is transparent, but the idea of chunking the collection into blocks of x may not be a bad workaround.
Hey! don't sound so surprised ...
On 27 April 2010 21:16, Bruce Gruenbaum
From an OOD perspective, the right answer here is, of course, a collection.
If you were unwilling to use an ABL implementation of a collection, you could take a page from the M-S-E model and use a TT in CalendarItem with a query with an external interface which allowed walking the set, but no direct access to the TT handle or the query handle so that no additions or deletions could be made.
JMLS - not just even a pretty face.
Actually, Bruce wasn't surprised since he and I have been talking about an idea related to this, but all within a single collection object, not separate objects. Stay tuned ....
Yeah... except we hadn't discussed the idea of a set of objects that each has an array in them.
Julian's idea got me thinking... We could create a linked list of objects that each contains an array. Thus you could grow the original array in chunks. You still have the issue of pointer to item "n", but it's derivable. This actually has a lot of potential.
We can consider it. It has the plus of being potentially open ended, but the minus of adding another layer of indirection and increasing the number of objects in the pool. Whereas, my proposal is closed end, but with the multiple constructor approach is upper bound can easily be large enough to be effectively open, while minimizing the number of objects and providing a simpler and more direct implementation.
The Vector object in Java owns a simple extent with a preferred size. When that extent gets full, its makes a new extent with twice the size. An integer holds the number of set items. FYI
This is along the lines of something we are exploring ... but we actually have quite a pool of ideas now.