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! > _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
