[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