ThinkGeo.com    |     Documentation    |     Premium Support

Opening and Closing layers

#1

I find myself frequently accessing some aspect of a layer that requires that the layer be open.   Something as simple as getting the extent of a layer requires this.   And, inevitably, I fail to do this.   I'm working only with custom layers and feature sources at this point.   Do the standard layers like shapefiles, etc, have this requirement, or is there intelligence within those objects to detect that the layer or feature source is closed and automatically open it.


I started to add this intelligence to my layer implementations, but then I wondered if that was a mistake.  At a minimum, it would be inconsistent with your implementation.   But I wondered what the architectural reasons were for not having auto-open functionality built into the layer objects.


 



#2

Ted, 
  
   This was a design decision, let me explain. It would not be hard to automatically open the feature source or layer once someone has accessed one of the properties.  The issue that comes up is the user not being aware of the state the layer is in can cause memory leaks and resources accidentally being left open.  We are also in an environment where we use serialization and to do that the feature source or layer needs to be closed.  I guess we could always check that ourselves though.  This also helped us in our development as it made is have to be aware of what the state was of our important resources.  We tried to make sure things were very efficient in the drawing process and sometimes we wrote some code on startup that needed a property but when we found it was not opened it made us aware that we really couldn’t afford to make that call as opening the feature source for some source has overhead.  In this way it helped us write more efficient code.  We took a page out of FileStream where you have to open the stream first and then close it when you are done.  If you try and call a method on a stream that has not been opened it will not try and open it for you as far as I know.   
  
 We do get allot of feedback on this and we tried to implement it the most correct way we knew how trying to make it safe and purposeful.  Of course safety has a price.  At the same time I would be willing to re-evaluate this.  I think we could add the smart logic to it without breaking binary compatibility however once we made the chance it would hard to go back since people would never need to call the open so from a code comparability standpoint this is a one way street.  I hope this sheds some light on this issue, it is a damned if you do and damed if you don;t kind of trade off. 
  
 David

#3

Reviewig it in light of your full discussion, I think you made the right choice.

#4

Ted, 
  
   It is one of those choices that I was pretty sure was right but hated to make because it even bites me when I write samples from time to time. 
  
 David