Hi Eric, Thank you for your response. I have a lot more working now, but I'm afraid I did not explain part of my problem very clearly before. Let me first try to explain that better as it will put into context some of my questions. What I'm struggling with is keeping the feature data in the browser in sync with the data in the database when we are editing. Let me talk through each of the CRUD examples.
Create: We create a new feature in OL, and display it in the vector layer. The feature is saved to the server where a GID is assigned to it. I can have the server respond by sending back the complete feature in response to the create request. I now need to delete the "temporary" feature and replace it with the completed feature. So I think I just figured out that I should hook the code for this to the create callback. Read: This is straight forward and just gets data from the server and clears the layer and repopulates it. No problems here. Update: I have two update cases because of how I built the UI: 1) update my dragging feature to new location (modifyfeature control) 2) update by editing attributes (select control) After the feature is modified, it is sent to the server via UPDATE. Again the issue is how to keep them in sync. I can also have the server respond with the updated feature and replace the vector feature with the one returned from the server using the callback. Delete: I think this one is a little easier, we wait for the server 200 response and then remove the feature in the vector layer. I did run into a problem with delete in that it does not appear to have a way to say WHAT to delete. In OL2.8, it appears that the data line is missing: resp.priv = OpenLayers.Request.DELETE({ url: url, callback: this.createCallback(this.handleDelete, resp, options), headers: options.headers, data: this.format.write(feature) // missing in OL2.8 }); or is it communicating that some other way? I passed an new delete: function(){...} in my protocol constructor and that seems to have fixed the problem. Does this sounds like the right approach for updating the features as they change during editing? or are there better practices. I currently have the OL application generating all the requests correctly as far as I can tell. The server is getting them, and ignoring them at the moment until I finish coding the appropriate server behaviors. http://imaptools.com:8080/tilecache/test.html?zoom=17&lat=33.89595&lon=35.49935&layers=BT Many of my questions below were coming from: 1) the fact the I had not understood how Protocol.HTTP worked, I think I have the basics of this down now and 2) the fact that the popup form really does not know what feature it is working on. When the form is rendered that code has access to the feature and populates the form fields and form is rendered and the code goes out of scope. Later the user fills in the form and clicks a button which causes the onClick handler to be called, the onClick handler code does not know what feature it is working with. I resolved this problem by saving a reference to the feature at mytoolbar.selCtrl.openpopup.feature which the onClick handle can now access. I was trying to avoid using global references, but this works fine and allowed me to move forward with the code. I suppose I could have add a hidden variable to the form with the feature DOM id and recovered the feature using that. Thank you for your time and your comments. They were very helpful and pointed me the right direction where I adequately explained myself. I think I just have a couple more pieces of code to finish up and some server side work to have a running application. Best regards, -Steve Eric Lemoine wrote: > On Saturday, March 13, 2010, Stephen Woodbridge <wood...@swoodbridge.com> > wrote: >> Hi all, >> >> I'm stuck on the best conceptual approach to editing feature attributes >> and could really use some feedback or other ideas. In part because I >> think I'm too tangled in all the code parts and have lost the big picture. >> >> So at a high level I need: >> >> 1) base map - check works fine >> 2) vector layer pulling data from server - check works fine >> 3) toolbar with [Nav][createPOI][dragPOI][selectPOI] - check have this >> but might need to rethink it >> 4) [createPOI] >> a) needs to take click on map - check, works fine >> b) open popup to allow setting attribute, check have this but ... >> c) have [cancel] to abort creation - have button but how to abort > > for a new feature "cancel" should just destroy that feature. > > for an updated feature "cancel" should go back to the initial feature, > cloning the feature prior modification may help. > >> d) have [save] to write the data to the server - have button but how >> to save > > If you use a protocol you can use protocol.create([feature]) or > protocol.commit([featute]). I'm not sure I'm answering your > question... > >> e) update layer with new feature - not sure the best way to do this. > > what do you mean? > >> 1) get return gid from server, add it to feature, and feature to layer > > I'd recommend you look at the Strategy.Save code. > >> 2) destroy the temporary feature, and have server return a complete >> feature that gets added to layer >> 3) not sure how to hook either of these into the code >> 5) [dragPOI] - check works, needs a myXML writer I think >> 6) [selectPOI] - check, have this but not everything works >> a) open popup to allow editing attributes - check have this, but ... >> b) have [delete] which will delete the feature >> c) have [cancel] which will cancel the edits >> d) have [save] which will save the edits to the server >> e) update the layer with the modified feature - again see [createPOI] >> >> So where I'm getting caught up is that in form button onClick function >> you really do not know what feature you are dealing with > > Hmm... when do you open the popup? I'd say when a new feature is drawn > on the map and when a feature is selected for modification. So when > you have an open popup you know the feature you are dealing with, no? > >> so I guess that >> means that the selected feature needs to be listening for events >> "abort", "cancel" and "save" that correspond to the buttons. and all the >> function should try to do is trigger the appropriate event. And that the >> listener should also have the responsibility for closing the popup. >> >> 1) So where should the listener be attached, I suppose to the vector >> layer as Alexandre suggested in earlier email, but that did compute yet. >> >> 2) thoughts on best practice for updating the modified features? > > Sorry I don't understand this question? > > Cheers, > _______________________________________________ Users mailing list Users@openlayers.org http://openlayers.org/mailman/listinfo/users