OpenLayers OpenLayers

Ticket #1154 (closed feature: fixed)

Opened 10 months ago

Last modified 9 months ago

OpenLayers.Format.* classes should be able to read,write and store different entity types

Reported by: ahocevar Assigned to:
Priority: minor Milestone: 2.6 Release
Component: general Version: 2.5
Keywords: Cc:
State:

Description

Currently, OpenLayers.Format.* classes do not read in all aspects of a provided document. Examples:

  • GeoRSS feeds do not only have items (=features), but also global information at the channel level like title, creator or category.
  • SLD documents have a hierarchy of entities, containing the style information at the bottom

All Format classes have only more or less static methods (except for some properties that control how documents should be read/written). Shouldn't those classes be able to store content, with the positive side effect of giving the user structured access to different entity types within the document instead of ignoring all but one of them? This would also be helpful for writing documents with a more complex structure, like GeoRSS or SLD.

My proposal would be to give all Format classes a content property. In the case of GeoRSS, this could look like that:

/**
 * APIProperty: content
 * {Object} containing
 *     - channel - {Hash of String} properties at the channel level, keyed by property name.
 *                 Supported property names are title, category, creator [...]
 *     - items   - {Array(<OpenLayers.Feature.Vector>)}
 */
content: {
    channel: null,
    items: null
}

For SLD, where the structure is more hierarchical, the content could provide a flat and a keyed storage for the userStyles. Helper methods can be created to get even more different views on the content conveniently:

/**
 * APIProperty: content
 * {Object} containing
 *     - namedLayer - {Object} hash of userStyles, keyed by sld:NamedLayer/Name,
 *                    each again keyed by sld:UserStyle/Name. Each entry of namedLayer
 *                    is a style map for a layer, with the userStyle names as style keys.
 *     - userStyles - {Array(<OpenLayers.Style>)}
 */
content: {
        namedLayer: null,
        userStyles: null
}

/**
 * APIProperty: overrideDefaultStyleName
 * {Boolean} if true, userStyles with sld:IsDefault==1 will be stored with name "default"
 * instead of the sld:UserStyle/Name for this property.
 */
overrideDefaultStyleName: true

/**
 * APIMethod: getStyleMap
 * Fetches a StyleMap for a specific layer name
 *
 * Parameters:
 * - layerName - {String} name of the layer for which we want a StyleMap
 *
 */
getStyleMap: function(userStyles) {}

Generally, the read() method should maybe return the main entity type, as it does now (for compatibility reasons), but it should also fill the content object. The write() method can also maybe continue to take the main entity type as an argument, but for some formats this information will not be sufficient. A complete dump will only be possible when the content object is properly filled before writing.

Change History

11/16/07 18:01:17 changed by ahocevar

  • milestone set to 2.6 Release.

12/15/07 08:24:37 changed by crschmidt

  • state changed.

I think a better API to this, rather than having things on the format object, is to support 'options' to read/write as a second parameter. (The Format.WFS fucks this up due to my stupidity, and in that case, it should be the third parameter.) The "options" would allow you to pass additional information that would affect the output of the 'read' return -- so the default continues to be, for example, a list of features from GeoRSS, whereas you can pass a {'feedInfo': true}, and if you do that, you get back:

  [features], {'title':'my feed title'}

etc.

Does this make sense? Does it solve the problem?

(follow-up: ↓ 5 ) 12/15/07 08:26:35 changed by crschmidt

I think a better API to this, rather than having things on the format object, is to support 'options' to read/write as a second parameter. (The Format.WFS changes this due to my stupidity, and in that case, it should be the third parameter.) The "options" would allow you to pass additional information that would affect the output of the 'read' return -- so the default continues to be, for example, a list of features from GeoRSS, whereas you can pass a {'feedInfo': true}, and if you do that, you get back:

[features], {'title':'my feed title'}

etc.

Does this make sense? Does it solve the problem?

(in reply to: ↑ 4 ) 12/15/07 10:29:53 changed by ahocevar

  • state set to Needs Discussion.

Replying to crschmidt:

I think a better API to this, rather than having things on the format object, is to support 'options' to read/write as a second parameter. (The Format.WFS changes this due to my stupidity, and in that case, it should be the third parameter.) The "options" would allow you to pass additional information that would affect the output of the 'read' return -- so the default continues to be, for example, a list of features from GeoRSS, whereas you can pass a {'feedInfo': true}, and if you do that, you get back: [features], {'title':'my feed title'} etc. Does this make sense? Does it solve the problem?

At least to me, it does make sense, and it solves the problem. So the Format classes stay static. If others also agree, I will change the patch for #533 (OpenLayers.Format.SLD) to make use of that (because currently it uses the API I proposed).

12/15/07 16:06:19 changed by ahocevar

See #533 for an example; the new patch sld-newapi.diff uses the API proposed by crschmidt.

12/19/07 16:48:20 changed by tschaub

  • status changed from new to closed.
  • state deleted.
  • resolution set to fixed.

Yeah, I'm thinking the same thing. The GeoJSON format is close - but we also messed up with the signature there. format.read(data, options) is pretty natural feeling to me. And you expect the return to change based on the options.

I don't really see anything here for review, so I think this is ready to be closed. Please reopen if I missed something. I'll check out #533 now (a three digit ticket number!!!).