(bug?)
I think this is a GeoExt issue but may be wrong (feel free to close it).
See this issue - http://code.google.com/p/geoext-viewer/issues/detail?id=167

The print preview scale bar doesn't use the projection that's been declared elsewhere. Other scale bars are all fine (the main map one and the MapFish printed output).

To work around it I have to explicitly declare the proj4js EPSG:

Proj4js.defs["EPSG:27700"] = "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +datum=OSGB36 +units=m +no_defs ";
EPSG27700 = new OpenLayers.Projection( "EPSG:27700" );

This page links to an "Example" that is a 404:
http://trac.geoext.org/wiki/ux/StreetViewPanel

To reproduce the issue:

• http://api.geoext.org/1.0/examples/popup-more.html
• Click on the map to open a popup
• Click between the anchor and the bottom of the popup

Expected: a new popup opens

Hi,
the featureFilter config on Geoext.data.FeatureStore has no effect.
I use GeoExt 1.1 with ext-js 3.4.0 and OpenLayers 2.12.
The store uses a GeoExt.data.ProtocolProxy to get features from a WFS. On that store I set the featureFilter-configOption in order to only display (and request) a subset of the available features in the grid. However, the filter does not get evaluated and all features are requested and show up in the grid.
Attaching the filter to the protocol works fine.

Debugging GeoExt.data.FeatureStore, I find that the code to evaluate this.featureFilter in onFeaturesAdded()-method never gets executed.

Here is the code for the grid panel:
gridPanel = new Ext.grid.GridPanel({
ref: 'featuregrid',
title: 'Tabellenansicht Parkhäuser',
region: 'north',
height: 200,
sm: new GeoExt.grid.FeatureSelectionModel(),
store: new GeoExt.data.FeatureStore({
fields: [
{name: "name", type: "string"},
{name: "art", type: "string"},
{name: "frei", type: "string"},
{name: "received", type: "string"}
],
proxy: new GeoExt.data.ProtocolProxy({
protocol: new OpenLayers.Protocol.WFS({
url: "http://gateway.hamburg.de/OGCFassade/Test_HH_WFS_Fachdaten.aspx",
version: "1.1.0",
featureType: "verkehr_parkhaeuser",
featureNS: "http://www.deegree.org/app",
srsName: "EPSG:25832"
})
}),
featureFilter: new OpenLayers.Filter.Spatial({
type: OpenLayers.Filter.Spatial.BBOX,
value: new OpenLayers.Bounds(563768,5932433,568001,5935608),
projection: "EPSG:25832"
}),
autoLoad: true
}),
columns: [
{header: "name", dataIndex: "name"},
{header: "Art", dataIndex: "art"},
{header: "Freie Stellplätze", dataIndex: "frei"},
{header: "Aktualität", dataIndex: "received"}
]
});

Best,
Sebastian

This issue was found in Heron (https://code.google.com/p/geoext-viewer/issues/detail?id=235) but applies to the function GeoExt.form.toFilter in

https://github.com/geoext/geoext/blob/master/lib/GeoExt/widgets/form.js

Problem is that in some forms with OR-ed fields where the user leaves fields empty and when wildcarding is enabled, the toFilter function will still add a wildcard to an empty string. In the worst case one may get the entire content of a DB. FIx is to skip filter encoding for fields with value is empty string and when wildcarding is one. We fixed this in Heron by overriding (also fixing other stuff), but may supply the fix as a pull as well. See fixed version here (line 267):

https://code.google.com/p/geoext-viewer/source/browse/trunk/heron/lib/override-geoext.js

Recent versions of MapFish Print (at least from june 2013 onward) take the TMS tileOrigin into account when rendering print output on "create". The current GeoExt encoder in PrintProvider.js does not take this into account. I have fixed this by extending the TileCache base encoder (called by the TMS encoder) as follows:

        "TileCache": function (layer) {
            var enc = this.encoders.layers.HTTPRequest.call(this, layer);
            // Heron fix JvdB 6 oct 2013
            // Add tileOrigin otherwise MapFish Print will be confused.
            // https://github.com/mapfish/mapfish-print/issues/68
            var maxExtent = layer.maxExtent.toArray();
            var tileOriginX = layer.tileOrigin ? layer.tileOrigin.lon : maxExtent[0];
            var tileOriginY = layer.tileOrigin ? layer.tileOrigin.lat : maxExtent[1];
            return Ext.apply(enc, {
                type: 'TileCache',
                layer: layer.layername,
                maxExtent: maxExtent,
                tileOrigin: {x: tileOriginX, y: tileOriginY},
                tileSize: [layer.tileSize.w, layer.tileSize.h],
                extension: layer.extension,
                resolutions: layer.serverResolutions || layer.resolutions
            });
        },

So "tileOrigin" is determined from the TMS tileOrigin if provided or the Map/Layer maxExtent LL coords. Yes the tileOrigin should be encoded as an Object with either x,y or lon,lat. Possibly needs refinement. According to the TMS spec (wiki) tileOrigin may be independently defined from maxExtent.

This came out from a longstanding MapFish Print issue:
mapfish/mapfish-print#68

See code at bottom of:
https://code.google.com/p/geoext-viewer/source/browse/trunk/heron/lib/override-geoext.js but I can provide a pull if neccessary.

A Heron user found an issue when using PrintMapPanel (via ux PrintPreview) with an "irregular" resolutions array for a TMS layer. Diving into this I found an old GeoExt ticket on Trac: http://trac.geoext.org/ticket/306. It appeared to be solved, but the committed code was taken out from PrintMapPanel in a later commit:

Patch went in this revision (see e.g. line 227):
https://github.com/geoext/geoext/blob/613eaa8836a13c88f727fbbfdbe5148c14604195/lib/GeoExt/widgets/PrintMapPanel.js

But went out, possibly by accident, in a next commit:
geoext/geoext@ac5de9a#lib/GeoExt/widgets/PrintMapPanel.js

I have made a fix for Heron which worked (just copying with slice(0) the resolutions array from the source map) by overriding PrintMapPanel.initComponent:
http://lib.heron-mc.org/heron/latest/lib/override-geoext.js

I can supply a patch/pull if you like. Possibly also affects GeoExt2?

In GeoExt/widgets/form.js, at line 134. I changed the following to support enumeration constraints for string.

if(type.match(r["text"])) {
    if(restriction.enumeration)
    {
        // Must convert the array into an array of array.
        var enumeration = new Array();
        for ( var i = 0, c = restriction.enumeration.length; i < c; i++ ) {
            enumeration[i] = [restriction.enumeration[i]];
        }

        var enumerationStore = new Ext.data.ArrayStore({
            data   : enumeration,
            fields : [label]
        });

        field = {
            xtype: "combo",
            name: name,
            fieldLabel: 'Letter',
            store: enumerationStore,
            mode: 'local',
            valueField:label,
            displayField:label,
            typeAhead: false,
            forceSelection: true
        };          
    }
    else{
        var maxLength = restriction["maxLength"] !== undefined ?
            parseFloat(restriction["maxLength"]) : undefined;
        var minLength = restriction["minLength"] !== undefined ?
            parseFloat(restriction["minLength"]) : undefined;
        field = {
            xtype: "textfield",
            name: name,
            fieldLabel: label,
            maxLength: maxLength,
            minLength: minLength
        };
    }
} else if(type.match(r["number"])) {

MapFish Print allows multiple output formats to be generated apart from the default PDF. The info capabilities will in general return a list of possible outputs like 'pdf', 'jpeg', 'png' etc in the MFP info.json capabilities outputFormats field. Actual format values can be controlled in the YAML file. The field outputFormat can subsequently be used to set a specific output format in the create.json request. To allow actual outputFormat selection, a number of classes in GeoExt and the PrintPreview UX need to work in concert. The pattern is very similar to DPI and layout selection:

The classes affected are:

GeoExt.data.PrintProvider:

• populate an outputFormats JSONStore
• manage the actual value (using outputFormat Record, events, etc)

GeoExt.plugins.PrintProviderField:

• manage changes in the selector (combo) widget with GeoExt.data.PrintProvider

GeoExt.ux.PrintPreview (extern)

• create an (optional) GUI widget (combobox) for selecting output

I have an example implementation that I can make into a Pull Request for the GeoExt classes. All should be forward compatible, i.e. only if outputFormat selection is enabled. PrintPreview is not in GeoExt repo, but I have an example as well.

See the example here (use normal print icon for print dialog window):

http://lib.heron-mc.org/heron/latest/examples/printdialog
and sources
https://code.google.com/p/geoext-viewer/source/browse/#svn%2Ftrunk%2Fheron%2Fexamples%2Fprintdialog
and printpreview changes:
https://code.google.com/p/geoext-viewer/source/browse/trunk/heron/ux/printpreview/lib/GeoExt.ux/PrintPreview.js

Here's the link for my problem : http://gis.stackexchange.com/questions/197797/commiting-changes-wfs-t-problem-with-base-layer-update

Long story short, the app works perfectly without a baselayer. once I add one, anyone. committing changes stops working. I followed your tutorial perfectly (WFS-t Made easy with GeoExt).
Please I'm desperate for a response.

http://dev.sencha.com/deploy/ext-3.4.0/examples/panel/bubble-panel.html

Hi everyone,

I'm wondering about GeoExt 2.0 compatibility with Extjs 5.0
We're testing our app with Extjs 5.0 Trial and there seems problems with GeoExt.Popup. Everything else is just fine.

Hi, there's a collegue of mine which has a geoext1.* istance (Jan 16 2013) running and a google base layer stopped working few months ago.
Is there any issue with bigG layers for this old geoext release?

Best regards

There is an unwanted comma here: https://github.com/geoext/geoext/blob/master/lib/GeoExt/data/PrintProvider.js#L367

This break IE8... (yeah... I know...) compatibility...

It would be nice if VectorLegend could interpret a KML format layer and render a proper legend based on styles from kml.

If the user rotate the print caneva, some vector features are ignored and not included in the print json.
This is because the reference bounds used to determine if vector features are included or not is always the un-rotated page bounds.

See https://github.com/geoext/geoext/blob/master/lib/GeoExt/widgets/grid/FeatureSelectionModel.js#L105. I haven't investigated whether this is wanted, but I have doubts.

Have Print Preview ux expose the OpenLayers attribution variable to MapFish Print. Maybe as mapAttribution.

When clicking the map, the popup is not anchored to the mouse position.

After fa884d3, the anchored config options is set to false is not valid location is passed to the constructor option.

Expected behavior: http://api.geoext.org/1.1/examples/popup-more.html

If a WMSLegend is configured with a URL, and baseParams e.g. contain a FORMAT, the FORMAT gets appended even if the original URL already has a FORMAT param.

We really need to turn all params into an object, uppercase them, and compare them against uppercased baesParams to make sure we don't duplicate any. Whether we override or ignore is a different question - but baseParams implies that we ignore params that are in the URL already.

This repository will be renamed to geoext1. As part of this all links on https://geoext.org/v1/ to https://trac.geoext.org/ will be replaced by a link to this repository.

In the future https://trac.geoext.org/ might get turned off. If this causes any issues for you, please contact [email protected] .

See: http://cdn.sencha.com/ext/commercial/3.4.1.1/release-notes.html

GeoExt.form.recordToField should take the above into account.

It would be nice if one could change the control associated to a GeoExt.Action on-the-fly.

I found this code on the mailing list. It seems to be a good starting point.
http://www.geoext.org/pipermail/users/2011-March/002083.html

The following line in WFSCapabilitiesReader.js throws an error if the GetCapabilities version is set to 1.1.0

var protocolDefaults = { 
    url: data.capability.request.getfeature.href.post 
}; 

The XML for GetCapabilities 1.1.0 does not include a capability section (as version 1.0) did. For example compare:

http://www2.dmsolutions.ca/cgi-bin/mswfs_gmap?version=1.1.0&request=getcapabilities&service=wfs
http://www2.dmsolutions.ca/cgi-bin/mswfs_gmap?version=1.0&request=getcapabilities&service=wfs

It will throw a TypeError: data.capability is undefined.

It looks like this has been brought up on the mailing list previously - http://www.mail-archive.com/[email protected]/msg01703.html