Opened 16 years ago
Closed 16 years ago
#56 closed defect (fixed)
Fusion's implementation of QUERYMAPFEATURES does not support LAYERATTRIBUTEFILTER
| Reported by: | jbirch | Owned by: | madair |
|---|---|---|---|
| Priority: | P2 | Milestone: | 1.0.5 |
| Component: | MapGuide | Version: | 1.0.4 |
| Severity: | Major | Keywords: | |
| Cc: | Browser: | All | |
| External ID: | Operating System: | All | |
| state: | Approved |
Description
Currently, in order to use tooltips with Fusion, users must mark layers in the MapDefinition as selectable. This appears to be because Fusion is not employing the LAYERATTRIBUTEFILTER bitmap which was introduced in MapGuide RFC 15
This should be supported to ensure that the maps behave the same in Fusion maps as they do in the MapGuide AJAX viewer.
Attachments (3)
Change History (8)
comment:1 by , 16 years ago
by , 16 years ago
| Attachment: | layerattributefilter_trunk.patch added |
|---|
Patch against trunk (untested)
by , 16 years ago
| Attachment: | layerattributefilter_1_0_x.patch added |
|---|
Somebody's got a crappy regex....
comment:2 by , 16 years ago
| Milestone: | → 1.0.5 |
|---|---|
| state: | New → Review |
I was able to test this change as working against the 1.0 branch. I was unable to test against trunk; I kept getting an error about DomNode not defined. I'm hoping that this is because of the Prototype refactoring? Anyway... review would be appreciated.
There's an additional parameter called FeatureFilter that was added in RFC15 because MapGuide's viewer search first does two queries, and querying against geometry can sometimes mean that the wrong feature is returned the second time around. I don't know enough about the search mechanism in Fusion to determin whether the same potential for problems exits. Any comments?
P.S. I don't understand why the branch patch doesn't work with the syntax highlighting. Maybe I need to replicate the whole trunk/branches thing locally?
comment:3 by , 16 years ago
| state: | Review → Approved |
|---|---|
| Status: | new → assigned |
can you tell what is using DomNode in the trunk version? That shouldn't happen with the standard template in trunk.
Patch looks good, tested.
comment:4 by , 16 years ago
Maybe I'm not doing this right.
I added a MapTip to the standard template's ApplicationDefinition, and a MapTip div to its index.html. Once I did this, I started getting the DomNode error. It might not be a bad idea to add the MapTip to the standard template permanently?
comment:5 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
The value that should be used for tooltips is 5 (visible and has tooltips). The default value if none is specified is 3 (visible and is selectable).