On Monday, July 20, 2009, Alexandre Dube <ad...@mapgears.com> wrote:
> Hi Eric,
>
> Eric Lemoine wrote:
>
> (I never used Protocol.MapFish and Strategy.Save together, I'm curious
> to know why they don't play together)
>
>
>
>
> I haven't tried either, but in the past I tried the HTTP protocol +
> featureserver and the Save strategy wasn't able to read the insertedId of the
> response received. I should simply try it and see what's the status now...
right. But a patch was committed before 2.8, so there's chance that
the save strategy and the mapfish protocol actually work together.
>
>
>
>
> So long that the control user can be notified when a feature is
> deleted I don't see the value of having the control committing the
> changes.
>
>
>
>
>
> Ok
>
>
> I don't understand. Can't you listen to "featuredeleted" from your
> control and trigger saveStrategy.save()? (assuming Strategy.Save work
> with Protocol.MapFish).
>
>
>
>
> Yes. I just wondered if it was better to do it internally...
>
>
> Some general comments on your control: from my understanding the
> control has two activities, (1) when a feature is selected change its
> state and redraw it, (2) when some delete key is pressed trigger
> events. Since they are *independent* activities they could be done by
> independent controls, and I think I'd disagree with wiring independent
> activities within a single control.
>
> If we had support for composite controls in the base Control class one
> could do something like what follows to implement your delete
> control's behavior:
>
> var delCtrl = new OpenLayers.Control({
> handler: new OpenLayers.Handler.Keyboard({
> keydown: function(evt) {
> var delKey = ...
> if(delKey) {
> saveStrategy.save();
> }
> }
> }),
> controls: [
> new OpenLayers.Control.SelectFeature(
> layer, {
> onSelect: function(f) {
> f.state = DELETE;
> this.layer.drawFeature(f);
> }
> })
> ]
> });
>
>
>
> If I understand correctly, you would disagree to have this control added as a
> new OpenLayers official control because of its 2 independent actions, so you
> suggest instead I should define a customized control like above but it
> requires to have controls within the control to be automatically
> activated/deactivated on 'this' control activation/deactivation. Is that it ?
That's basically it, yes. But I may wrong, and there may be value in
combining these two independent activities (as a helper control), I'm
just not convinced at this point. To get to the delete control
>
>
> (the support for composing controls I mentioned above involves having
> the base Control class activates and deactivates every control that's
> passed in the "controls" option.)
>
> What do you think?
>
> Cheers,
>
>
>
>
> About the 'controls' property and the act./dea. automatism : that's a good
> idea, but wouldn't it be good to have a 'handlers' property also and
> activate/deactivate all handlers as well ? Currently, control has a
> 'handler' property only. Would it make sense to have 'handlers' added a do
> the same kind of automatism as the new 'controls' property ?
>
> Regards,
>
> Alexandre
>
>
>
>
>
>
> Any hint would be appreciated,
>
> Alexandre
>
> Alexandre Dube wrote:
>
>
> Hi,
>
> I just sent (finally) a new patch for ticket 1882 (1) (DeleteFeature
> control) and set the status to review.
>
> (1) http://trac.openlayers.org/ticket/1882
>
> Regards,
>
>
>
>
> --
> Alexandre Dubé
> Mapgears
> www.mapgears.com
>
> _______________________________________________
> Dev mailing list
> Dev@openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>
>
>
>
>
>
>
>
>
> --
> Alexandre Dubé
> Mapgears
> www.mapgears.com
>
>
--
Eric Lemoine
Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex
Tel : 00 33 4 79 44 44 96
Mail : eric.lemo...@camptocamp.com
http://www.camptocamp.com
_______________________________________________
Dev mailing list
Dev@openlayers.org
http://openlayers.org/mailman/listinfo/dev
