[OpenLayers-Dev] [vector-behavior] proposal for changes

Tim Schaub tschaub at opengeo.org
Mon Jul 21 10:18:36 EDT 2008


Hey-

In thinking about this a bit more, I'm even more convinced that layers 
activating/deactivating strategies (and not initializing/destroying 
them) will work.  In terms of potential memory leaks, activate and 
deactivate are more important to consider than initialize and destroy.

Eric Lemoine wrote:
> Tim,
> 
> Thanks for your response.
> 
> Having the application code responsible for creating and destroying
> strategies makes sense to me. What do you think we should do for
> "fomat" and "protocol"? Should we pass functions, or objects as for
> strategies?
> 
>> I agree with the layer activating and deactivating strategies.  We could
>> also include an autoActivate property (default is true).
> 
> If I understand you correctly strategies with autoActivate:true will
> be activated/deactivated by the layer. Something like that:
> 
> method setMap:
>     for each strategy:
>         if strategy.autoActivate:
>             strategy.activate()
> 
> method removeMap:
>     for earch strategy:
>         if strategy.autoActivate:
>             strategy.deactivate()
> 

Yeah, that's what I was thinking.  Don't have a specific case in mind 
where autoActivate would be false - but I can imagine an application 
where the user had control over layer behavior (turning on/off a 
strategy maybe).

In terms of formats and protocols, it would be more consistent to pass 
objects I guess.  Maybe someone else has an opinion - we're not 
registering event listeners on dom elements here (so this is not likely 
a source of leaks in that realm) - this is mostly about creating a few 
ActiveXObjects or DOMParsers and not destroying them (in most cases this 
wouldn't happen until unload any way).

We could always just say the layer destroys strategies, protocols, and 
formats on layer.destroy.  This would be consistent with the map 
destroying controls (that it did not create), and the layer destroying 
features (that it did not create).

Tim

> --
> Eric
> 
> !DSPAM:4033,4880402822453668746562!
> 




More information about the Dev mailing list