[OpenLayers-Dev] [vector-behavior] comments on recent commit

[Eric Lemoine]

Hi Tim. Yes i was indeed thinking about giving each feature an events
instance. I agree with you that we should consider performance. In any
way, my point is that vector layers should not be responsible for
triggering featuredestroyed events as features can be destroyed
directly without going through the vector layer. Thanks. Eric

2008/6/27, Tim Schaub <tschaub at opengeo.org>:
> Hey-
>
> Eric Lemoine wrote:
>> Tim,
>>
>> Some comments on your recent commit to vector-behavior (r7386). You
>> trigger "featuresdestroyed" while this event isn't in the EVENT_TYPES
>> array. Did you really want to trigger that event?
>
> This was probably the result of a sloppy merge on my part.
>
> I'll take a closer look as time permits.
>
>>
>>  In any way, I'm wondering if the vector layer should be responsible
>> for triggering "feature(s) destroyed" type events. One can do
>> feature.destroy() and in that case the layer doesn't even know the
>> feature is being destroyed. For that reason, I think it's the
>> feature's responsibility to trigger "featureremoved". Going further, I
>> think features should not be linked to a layer (currently features
>> have a "layer" property), vector layers should listen to
>> "featuredestroyed" events triggered by the features themselves and do
>> the job of removing the feature when such an event occurs.
>
> You mean give each feature an events instance?
>
> I don't think it's a bad idea to make more stuff observable - but I
> think we might want to look at any performance implications of this
> first (and perhaps consider how this could be done differently in 3.0).
>
> Tim
>
>>
>> Thanks,
>> --
>> Eric
>> _______________________________________________
>> Dev mailing list
>> Dev at openlayers.org
>> http://openlayers.org/mailman/listinfo/dev
>>
>> !DSPAM:4033,485b359d34206491211187!
>>
>
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>