HI, We work with WFS on a daily basis, but not with transactional. Does that patch apply to us as well? If so, we would be happy to help.
Julien Tim Schaub wrote: > Hey- > > So, tests are now passing with the WFS protocol. I think this is pretty > close and would appreciate any help creating tests, trying it out, etc. > > The patch [1] includes a very basic Save strategy. This is a manual > save strategy (requires that you call save). It can be used as the > basis for auto or greedy save strategies, but I think we should keep it > simple for this patch. > > Thanks for any assistance testing/reviewing. > > Tim > > [1] http://trac.openlayers.org/ticket/1648 > > Tim Schaub wrote: > >>Hey- >> >>I put up a patch that represents progress towards a working WFS protocol. >> >>http://trac.openlayers.org/ticket/1648 >> >>I'll work on it a bit more tomorrow. Please feel free to pick it up and >>push it forward (anyone). The wfs-protocol-transactions.html example is >>a good place to start with a debugger. In the end, this example will do >>inserts, updates, and deletes (with a commit from the save button). >> >>Tim >> >>Björn Harrtell wrote: >> >>>I have been making a serious (relatively? :) attempt at understanding >>>what is to be done regarding Protocol.WFS and related classes. I looked >>>at it from the angle in which it would be useful for me in the case I >>>described before. >>> >>>* the standard WFS-T >>>* Fixed and Save (and perhaps SaveGreedy) strategy >>> >>> From I can gather none of these are far from complete, but what I'm >>>missing is option to filter the input in Fixed strategy. I noticed that >>>the trunk version of BBOX strategy looks for additional filters in the >>>layer and while it might be a good place put the additional filter I >>>can't see any indication that Layer actually is supposed to support such >>>a property. If it should it should be documented and used by fixed >>>strategy also? >>> >>>I would like to to implement this before beeing able to do serious >>>testing. I nice thing is that I could test stuff directly in a real >>>world case where I'm using (successfully) the clumsy old Layer.WFS way >>>with a temp layer. But before that I would like to confirm that I got >>>the right idea... >>> >>>A question on the side... why are some methods declared "JSONy" i.e >>>'read' instead of read? >>> >>>/Björn >>> >>>On Wed, Sep 17, 2008 at 2:10 AM, Tim Schaub <[EMAIL PROTECTED] >>><mailto:[EMAIL PROTECTED]>> wrote: >>> >>> Hey- >>> >>> Björn Harrtell wrote: >>> > Hi devs, >>> > >>> > I'm coding an application that uses OL vector editing and WFS >>> > transactions quite heavily. >>> > >>> > I use a temporary OpenLayers.Layer.Vector for editing, moving >>> stuff to a >>> > OpenLayers.Layer.WFS as the user makes edits. This is a bit >>> clumsy and >>> > complicated but works. The reason why I'm doing this is because >>> > OpenLayers.Layer.WFS only supports GET and is also loading >>> features on >>> > demand (hmm is this correct?) which doesn't fit my needs. Note >>> that I do >>> > not add the OpenLayers.Layer.WFS to a map, I only use >>> create/commit the >>> > WFS transactions. >>> > >>> > I would like to use something like a static/manually triggered WFS >>> > (supporting POST and filtering) source to an OpenLayers.Layer.Vector >>> > that syncs changes to the WFS source which then can be commited >>> > programmatically. >>> > >>> > Is this sort of what OpenLayers.Protocol.WFS (which I think is beeing >>> > worked on?) is supposed to be used for? Or would it be sensible >>> to make >>> > something more of OpenLayers.Layer.WFS instead? >>> >>> Yes, this is exactly the job for a WFS protocol. As Eric mentions, the >>> work is mostly in the vector-behavior sandbox. I'll make an effort to >>> update that and to get a patch ready for the trunk. >>> >>> My hope is to get the WFS protocol in the trunk before the end of next >>> week. Any help you can contribute would be appreciated. >>> >>> Watch the WFS protocol ticket [1] for updates from me, and leave any >>> comments/patches there that you put together. >>> >>> Tim >>> >>> [1] http://trac.openlayers.org/ticket/1648 >>> >>> >>> > >>> > Either way, I'm interested in (trying) to help out if this seems like >>> > something you would like to support in OL, and can probably do it >>> as a >>> > part of the current project as it would simplify things for me I >>> think. >>> > >>> > Regards, >>> > >>> > Björn Harrtell >>> > GIS Consultant >>> > SWECO Position AB >>> > <http://www.swecogroup.com/en/Sweco-group/Services/Geographic-IT/> >>> > >>> > >>> > >>> ------------------------------------------------------------------------ >>> > >>> > _______________________________________________ >>> > Dev mailing list >>> > [email protected] <mailto:[email protected]> >>> > http://openlayers.org/mailman/listinfo/dev >>> >>> >>> -- >>> Tim Schaub >>> OpenGeo - http://opengeo.org >>> Expert service straight from the developers. >>> _______________________________________________ >>> Dev mailing list >>> [email protected] <mailto:[email protected]> >>> http://openlayers.org/mailman/listinfo/dev >>> >>> >> >> > > -- Julien-Samuel Lacroix Mapgears http://www.mapgears.com/ _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
