Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AutoDetect FeatureInfo column width & Specify manual column width #333

Closed
GoogleCodeExporter opened this issue May 10, 2015 · 18 comments
Closed

Comments

@GoogleCodeExporter
Copy link

Ability to autodetect the width of a FeatureInfo column and set the column 
width appropriately.
- Max and min widths implementer configurable.

Also/alternately, ability for implementer to configure a fixed default column 
width. (Currently hard-coded to 100 pixels).

Original issue reported on code.google.com by [email protected] on 21 Jan 2014 at 5:52

@GoogleCodeExporter
Copy link
Author

See Attached for patch.
The Column autowidth detect is enabled by default. You may wish to change this, 
but I quite like it.

Usage examples:

autoMaxWidth : 400 //Set the maximum auto-detect column width to 400 pixels. 
Set to 0 (or below) to disable.
autoMaxWidth : 50 //Set the minimum auto-detect column width to 50 pixels (it's 
unlikely you'll ever want to set this - the default is typically fine)

defaultColumnWidth: 200 //All columns will be 200 pixels wide.


Notes:
- Takes advantage of the autoConfigMaxSniff stuff. Be sure it's set otherwise 
it will only scan the column name and first row.
- Seems to Work on all not-pre-configured grids.
- autoMaxWidth and defaultColumnWidth shouldn't be used interchangeably - it's 
pointless; It won't break, but autoMaxWidth will always win.

Possible improvements:
- The text width calculator is hardcoded to 7 pixels per character. This is 
suboptimal but broadly speaking provides passable results.
A proper solution (which should be pixel perfect widths) would be to use: 
http://docs.sencha.com/extjs/3.4.0/#!/api/Ext.util.TextMetrics - but ExtJS 
stuff isn't my ball game so I didn't do that. Someone else is welcome to if 
they want.

Original comment by [email protected] on 21 Jan 2014 at 6:17

Attachments:

@GoogleCodeExporter
Copy link
Author

Ok thanks for the patch: two problems though:

1. the patch is based on the original lib/widgets/search/FeatureGridPanel.js, 
has been renamed to FeaturePanel.js as par of issue 317
2. the original's date is Mon Dec 02 16:37:10 2013, a lot has been changed 
since (by Rinke mainly)

Can you maybe make a new patch based on the most recent  
lib/widgets/search/FeaturePanel.js?

Rinke can you do the integration as per the workplan?


Original comment by [email protected] on 22 Jan 2014 at 2:40

  • Changed state: Started
  • Added labels: Type-Enhancement
  • Removed labels: Type-Review

@GoogleCodeExporter
Copy link
Author

I did it against 1.0.0.

Can you show me where I can get the updated (and renamed) file from? I'll then 
create a new patch against that.

Original comment by [email protected] on 22 Jan 2014 at 2:46

@GoogleCodeExporter
Copy link
Author

I think best is to get the latest version from SVN. If you only supply patches 
you can chekout read-only using e.g. Tortoise SVN client. Or only the raw file, 
but then it would be hard to test: 
https://code.google.com/p/geoext-viewer/source/browse/trunk/heron/lib/widgets/se
arch/FeaturePanel.js

But maybe you may want to do real commits, I can add you as a committer. The 
advantage is now, that you can immediately test your results on 
http://lib.heron-mc.org/heron/latest/examples (provided you have added an 
example), or use the generated libs in your local app via http include of 
"latest".  That said: do you have, or plan to add, an example as well?

Original comment by [email protected] on 22 Jan 2014 at 2:57

@GoogleCodeExporter
Copy link
Author

I think it best to avoid me doing real-commits. Me and versioning systems don't 
get along.
I managed to do a checkout of the SVN and have used that. See attached. Seems 
to work OK.

Original comment by [email protected] on 22 Jan 2014 at 3:32

Attachments:

@GoogleCodeExporter
Copy link
Author

Rev 1271
Integrated the patch 

Added examples:
columnsautowidth
columnsfixedwidth

Original comment by [email protected] on 23 Jan 2014 at 2:41

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

Have to re-open this issue: a JS error is generated whenever an attribute value 
is null. This happens in rare cases, but found in e.g.  line 972 of 
FeaturePanel.js, first reported by Wolfram:
https://groups.google.com/forum/?hl=en#!topic/geoext-viewer-devel/S4zx0C0Kbg8

var columnWidth = feature.attributes[fieldName].length * pixelsPerCharacter;

To reproduce:
- go to example lib.heron-mc.org/heron/latest/examples/defaultnl
- select feature info/identify  button
- click on any address (blue points)


Original comment by [email protected] on 27 Jan 2014 at 3:58

  • Changed state: Started

@GoogleCodeExporter
Copy link
Author

Weird. I thought my data had null values in for testing. I'll investigate; I 
suspect I know what the solution is.

Original comment by [email protected] on 27 Jan 2014 at 4:07

@GoogleCodeExporter
Copy link
Author

I'm not seeing it. In my version if there is no data the column is ignored. If 
there is data but later on then the column is blank.

I'd like to try your version - in the example you linked, what layer do I need 
to turn on to get the blue points?

Original comment by [email protected] on 27 Jan 2014 at 4:13

@GoogleCodeExporter
Copy link
Author

Added wrong example link, should be:

http://lib.heron-mc.org/heron/latest/examples/vectorstyler

Original comment by [email protected] on 27 Jan 2014 at 4:14

@GoogleCodeExporter
Copy link
Author

Yep, that breaks. What's special about those points? What are their attributes?

Possible fix:
Place this on line 958:
                    if (typeof feature.attributes[fieldName] !== 'undefined' && feature.attributes[fieldName] !== null) {

And close the bracket on 978.
I can't replicate it here so can't test it.

Original comment by [email protected] on 27 Jan 2014 at 4:56

@GoogleCodeExporter
Copy link
Author

Fixed with revision 1279

The points are JSON records loaded from local file, but their origin is 
GeoServer WFS. Empty fields get null value appearantly while in GML they are 
left out..

    {
        "type": "Feature",
        "id": "inspireadressen.fid--7c58662c_1417f9b0434_419d",
        "geometry": {
            "type": "Point",
            "coordinates": [154916.08, 462107.93]
        },
        "geometry_name": "geom",
        "properties": {
            "gid": 95685909,
            "straatnaam": "Miereveldstraat",
            "huisnummer": 58,
            "huisletter": null,
            "toevoeging": null,
            "woonplaats": "Amersfoort",
            "postcode": "3817RP"
        }
    },


Original comment by [email protected] on 27 Jan 2014 at 5:06

  • Changed state: Fixed

@GoogleCodeExporter
Copy link
Author

Ah ok. Well that seems to have fixed it anyway, which is good. Thanks.

Original comment by [email protected] on 27 Jan 2014 at 5:16

@GoogleCodeExporter
Copy link
Author

Thanks for the quick correction! 
BTW: I've configured my featurepanel with gridCellRenderers to map the field 
content to an url:
...
Heron.scratch.gridCellRenderers =
[
    {
        featureType: 'db-nbz',
        attrName : 'NRBEZ',
        renderer :  {
            fn : Heron.widgets.GridCellRenderer.browserPopupLink,
            options : {
                url: '/ISD/SP_PDF_IVL/PdfIvlQuery.asp?PLADR={NRBEZ}',
                attrPreTxt: 'Ivl-Plan: '
                , winName: Heron.scratch.gridCellRenderers_WinISD.winName
                , bReopen: Heron.scratch.gridCellRenderers_WinISD.bReopen
                , hasMenubar: Heron.scratch.gridCellRenderers_WinISD.hasMenubar
                , hasToolbar: Heron.scratch.gridCellRenderers_WinISD.hasToolbar
                , hasAddressbar: Heron.scratch.gridCellRenderers_WinISD.hasAddressbar
                , hasStatusbar: Heron.scratch.gridCellRenderers_WinISD.hasStatusbar
                , hasScrollbars: Heron.scratch.gridCellRenderers_WinISD.hasScrollbars
                , isResizable: Heron.scratch.gridCellRenderers_WinISD.isResizable
                , hasPos: Heron.scratch.gridCellRenderers_WinISD.hasPos
                , xPos: Heron.scratch.gridCellRenderers_WinISD.xPos
                , yPos: Heron.scratch.gridCellRenderers_WinISD.yPos
                , hasSize: Heron.scratch.gridCellRenderers_WinISD.hasSize
                , wSize: Heron.scratch.gridCellRenderers_WinISD.wSize
                , hSize: Heron.scratch.gridCellRenderers_WinISD.hSize
            }
        }
    }
    ,
...
The automatic column width hides this MAIN information - also: if you switch to 
the detail view the gridCellRenderers are not shown.
Please have a look - I've attached three pics... 
Could I figure this out or is it a wish of refinement?

Original comment by wolfram.winter on 28 Jan 2014 at 8:22

Attachments:

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

Hi; No problem on the quick fix. :-)

The detail view and gridcell renderers is something for this issue: 
http://code.google.com/p/geoext-viewer/issues/detail?id=317 - it sounds like a 
bug, I'd certainly suggest reporting it.

----

Specific to your other issue:
That the columns are the wrong width for gridcellrenders - this is true and a 
known "issue". The column width is calculated before any gridCellRendering is 
performed.

It should be resolvable, but I think it would require de-optimising the code a 
little which is one reason I didn't do it at original implementation. The other 
being I'm not all that clear how gridCellRenderers work! :-)

Original comment by [email protected] on 28 Jan 2014 at 8:35

@GoogleCodeExporter
Copy link
Author

Fixed columnWidth for gridCellRenderers with attrPreTxt like 'wiki:' in rev 1288

Original comment by [email protected] on 29 Jan 2014 at 9:48

@GoogleCodeExporter
Copy link
Author

Tested - 'gridCellRenderers with attrPreTxt' works for me - thanks!!!

Original comment by wolfram.winter on 31 Jan 2014 at 10:25

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant