PdfParserProject | RecentChanges | Preferences

I just sent out the code I have for this class so far. While I was working on PdfReferenceFactory, I started wondering why this class is so important. If you look at the preliminary object model, it's really the only thing that ties a PdfFile to an instance of PdfParser. Which is why PdfReferenceFactory has a resolve() method to resolve references.

To summarize the problem, I don't think PdfParser should associate itself directly with a PdfFile. I'm thinking maybe the PdfFile class should handle resolving. Is the question just academic? Could we use another class, something called 'Resolver' which has as instance variables a PdfFile and PdfParser & handles all communication between them? Comments? --Ivan

It doesn't seem right that the PdfReferenceFactory has to be aware of the file or parser. It seems problematic to me that the resolve() method is in the PdfReferenceFactory, since it requires file operations; I think PdfReferenceFactory should just be managing the hashtable.

But putting resolve() in PdfFile seems wrong too because a file shouldn't care directly about its contents? The only place I can think of that should be implementing resolve() is the actual PdfReference? object. What if each PdfReference? object implemented the resolve() method instead, which would be invoked when someone wanted to dereference the reference? It would look like:


  PdfParser parse: (PdfFile getData: byteOffset)

PdfParser accesses the singleton instance of itself in a class method. But PdfFile having a class method getData is ugly.

Just brainstorming. This is all philosophical stuff... --Patty

Our final code has the resolve: method in the PdfReferenceFactory. We also found a problem with our PdfReferenceFactory. Our write scheme was to traverse the instance variable refPool (a standard Dictionary) to write all references to disk. We decided that this was the most comprehensive way to write all the PdfObject's to disk.

However the dictionary only stored mappings from "0:65535" to a PdfReference?. Nowhere was the resulting PdfObject (PdfString, PdfPageTreeNode) stored. We decided to "cache" these objects in a new instance variable "objectCache" which was a standard Dictionary. This cache would be populated on-demand as each PdfReference? was resolved. This simplified the write algorithm as well as providing a centralized place for all objects. I suspect that this was the Flyweight pattern again since it did ensure that all PdfObjects? were instantiated only once.

It's arguable that this class could be more appropriately renamed to be the PdfObjectFactory? because of the change in its function.

-- Patty

PdfParserProject | RecentChanges | Preferences
This page is read-only (last edited December 14, 2000 10:01 pm (diff))