[TinyOWS-users] Should the feature attributes order in XML matter ?
Jean-François Gigand
jean-francois at gigand.fr
Mon Feb 21 09:17:23 EST 2011
Ok...
The specifications (WFS + XML Schema) are clear about this
requirement, although in this case I also find it irrelevant.
Indeed, the WFS update requests are not required to respect any
particular column order, the spec is clear about it too!
The columns-order attribute proposal would save the WFS columns order
logical from any PostgreSQL alterations.
On the client-side, however, the attribute order matters, and, working
with the OpenLayers.Feature.Vector's "attributes" object must be done
with care. Since it is not usual to take care of property order within
objects.
For example, if the attrs are : "name", "stock", "comment"
The following code would fail at INSERT, because "comment" should be
after "stock":
feature.attributes.name = '...';
feature.attributes.comment = '...';
feature.attributes.stock = 42;
To let Javascript coding be free of this "protocol" requirement, I
have written a simple OpenLayers.Strategy which make sure the
attribute order requirement is met. See below. It's not related to
TinyOWS hence, however we are on this topic, so it can be useful.
///////////////////////////////////////
/**
* @requires OpenLayers/Strategy.js
*/
/**
* Allow to force the ordering of attributes before saving
*
* @class
*/
OpenLayers.Strategy.SaveAttrOrder =
OpenLayers.Class(OpenLayers.Strategy,
{
/**
* Order of attributes to save.
*
* Only the attributes listed here will be saved!
*
* @type {Array.<string>}
*/
order: [],
/**
* Strategy to communicate with for save operation
*
* @type {OpenLayers.Strategy.Save}
*/
saveStrategy: null,
/**
* APIMethod: activate
* Activate the strategy. Register any listeners, do appropriate setup.
*
* Returns:
* {Boolean} The strategy was successfully activated.
*/
activate: function() {
var activated = OpenLayers.Strategy.prototype.activate.call(this);
if (activated) {
this.saveStrategy.events.on({
start: this.beforeSave,
scope: this
});
}
return activated;
},
/**
* APIMethod: deactivate
* Deactivate the strategy. Unregister any listeners, do appropriate
* tear-down.
*
* Returns:
* {Boolean} The strategy was successfully deactivated.
*/
deactivate: function() {
var deactivated = OpenLayers.Strategy.prototype.deactivate.call(this);
if(deactivated) {
this.saveStrategy.events.un({
start: this.beforeSave,
scope: this
});
}
return deactivated;
},
beforeSave: function(event) {
var features = event.features;
features.forEach(dojo.hitch(this, 'reorderFeature'));
},
reorderFeature: function(feature) {
var obj = {};
this.order.forEach(
function(attr) {
if (feature.attributes.hasOwnProperty(attr)) {
obj[attr] = feature.attributes[attr];
}
});
feature.attributes = obj;
}
});
///////////////////////////////////////
Jean-François Gigand
2011/2/21 Gissur Þórhallsson <gissur at loftmyndir.is>:
> Actually, after looking more closely, I think libxml2 is innocent.
> I was inserting features with requests that contained only the geometry - it
> seems I tried adding attributes to the insert around the same time as I was
> upgrading my system. What mislead me is that INSERT worked for a small
> subset of my layers (which have only one attribute) - so that had me barking
> up the wrong tree.
> The matter remains that I can not INSERT except through some insufferable
> hanky-panky regarding column order on the database side - which for postgis
> and 13 layers is no picnic. The funny thing is that all of this is
> completely irrelevant when it comes to UPDATES.
> Anyway - I must agree with you that an optional columns-order element would
> be nice approach in fixing this.
> Kind regards,
> Gissur
>
> On Sat, Feb 19, 2011 at 2:26 PM, Jean-François Gigand
> <jean-francois at gigand.fr> wrote:
>>
>> Hi Gissur,
>>
>> Interesting!
>> I use libxml2 2.7.8 on Debian.
>>
>> I have spent quite some time check the WFS et XML schema specs.
>> I was surprised but this is the normal behaviour.
>>
>> If you noticed a difference between two versions of libxml2, I would
>> guess that the new version is right and the older was too tolerant for
>> this sequence elements order issue.
>> Maybe a clue could be find in the libxml2 change log...
>>
>>
>> JF
>>
>>
>>
>> 2011/2/19 Gissur Þórhallsson <gissur at loftmyndir.is>:
>> > I suddenly started getting this message too.
>> > I'm not entirely sure what happened - I've had tinyOWS running without a
>> > hitch for a couple of months now and then all of a sudden I start to get
>> > "xml is not valid"
>> > And peeping into the logs gives me:
>> > [Sat Feb 19 12:42:34 2011] [ERROR] Element
>> > '{http://my.namespaceurl.com/}area': This element is not expected.
>> > Expected
>> > is one of ( {http://my.namespaceurl.com/}date_created,
>> > {http://my.namespaceurl.com/}date_modified,
>> > {http://my.namespaceurl.com/}username,
>> > {http://geoserver.loftmyndir.is/}origin ).
>> >
>> > Funnily enough this does not happen to all layers - simple layers (as in
>> > with few attributes, in my case only numeric area and a text field for
>> > comments) seem unaffected.
>> > I can't for the life of my figure out why this popped up all of sudden -
>> > the
>> > only thing I can relate this to is a system-wide upgrade I made on my
>> > box,
>> > which is running ubuntu 8.0.4. LTS box- and if I correlate my
>> > tinyows.logs
>> > with /var/log/apt/term.log I see that the "Expected is one of [...]"
>> > only
>> > start to appear around the time I upgraded libxml2 to libxml2
>> > (2.6.31.dfsg-2ubuntu1.5) (I have no idea what version I was running
>> > before
>> > that).
>> > I'm going to see whether I can downgrade libxml2 and see if it changes
>> > anything.
>> > Or am I maybe barking up the completely wrong tree here?
>> > Kind regards,
>> > Gissur
>> >
>> >
>> > On Mon, Jan 31, 2011 at 10:05 PM, Jean-François Gigand
>> > <jean-francois at gigand.fr> wrote:
>> >>
>> >> Hi,
>> >>
>> >> For an 1.0.0 insert request, I get the exception "xml isn't valid"
>> >> with the following error:
>> >> [Mon Jan 31 21:11:05 2011] [ERROR] Element '{http://domain.net/}name':
>> >> This element is not expected. Expected is (
>> >> {http://domain.net/}deleted ).
>> >>
>> >> "name" and "deleted" are (among others) valid feature attributes.
>> >> If I change the attribute elements order in my test request XML file,
>> >> and follow exactly the PostgreSQL column order for that table, it
>> >> works.
>> >>
>> >> I am surprised. The WFS spec doesn't require a proper feature
>> >> attribute order in the list, does it?
>> >>
>> >> Having checked the w3schools doc about XML Schema, the <xs:sequence>
>> >> element requires the element order to be respected.
>> >> I see that validation is done by libxml2, and of course is done well.
>> >>
>> >> The problem, within the use cases of TinyOWS, is that PostgreSQL does
>> >> not provide any way to alter columns position.
>> >>
>> >> You would say that the app should anyway fetch the feature schema by
>> >> issuing a DescribeFeatureType request, and deal with the features
>> >> according to it...
>> >>
>> >> Actually, the OpenLayers serializer (exactly:
>> >> OpenLayers.Format.GML.Base.prototype.writers.feature._typeName)
>> >> creates the geometry first, then the attributes in object property
>> >> (for .. in).
>> >> If the geometry column in the PostgreSQL table is not the first (or
>> >> second after identifier), I could never insert any feature, and a
>> >> workaround with OpenLayers would be really messy.
>> >>
>> >> This would be an issue of OpenLayers of course. But I think it
>> >> wouldn't break the logic to add to the TinyOWS configuration an
>> >> optional "columns-order" attribute on the <layer> elements.
>> >> That attribute would contain the comma-separated list of columns to
>> >> export to the WFS client in the order they should be listed in the
>> >> DescribeFeatureType sequence.
>> >>
>> >> It would also allow to restrict the columns to export.
>> >>
>> >> What do you think?
>> >>
>> >> --
>> >> Jeff
>> >> _______________________________________________
>> >> TinyOWS-users mailing list
>> >> TinyOWS-users at lists.maptools.org
>> >> http://lists.maptools.org/mailman/listinfo/tinyows-users
>> >
>> >
>> >
>> > --
>> > Gissur Þórhallsson
>> >
>> > Loftmyndir ehf.
>> > Laugavegur 13
>> > IS 101 Reykjavík - Iceland
>> > sími (tel): (+354) 540 2500
>> > tölvupóstur (email): gissur at loftmyndir.is
>> >
>
>
>
> --
> Gissur Þórhallsson
>
> Loftmyndir ehf.
> Laugavegur 13
> IS 101 Reykjavík - Iceland
> sími (tel): (+354) 540 2500
> tölvupóstur (email): gissur at loftmyndir.is
>
More information about the TinyOWS-users
mailing list