ResultExtGrid - "use response fields" support

[adube]

currently

In the ResultExtGrid widget, you must manually define the list of fields to display for each resource (grid). When you have lots and lots of resources to query and show results, having to manually define all these fields can be really annoying.

Also, it is important to mention that this way of "showing certain fields only" is not secured. The query response contains all the fields and their values. It's not filtered in any way by the proxy. So, the 'fields' list in the widget options has only the purpose of showing those we want. You could do the same thing with mapserver (for example) if you defined the metadata "gml_include_items" (if I recall correctly).

So in the end, defining fields shouldn't be mandatory.

---

new feature

It would be nice to be able to define no fields at all and have all the fields returned by the query directly displayed instead.

For that, I propose a new boolean option "noFields" that would be "false" by default. Setting it to "true" would ignore the "fields" option and parse all fields directly from the query result.

Having no "fields" options at all shouldn't display all fields by default since that's already what it does and we want to be backward compatible.

[adube]

In fact, having no "grids" options at all would be nice too. A grid node has :

• resourcename --> would not be required since you already have the resource and widget linked together
• displayname --> we could use the resource title for that
• delegatecontext --> this options has no purpose there. It should under the root of the option node instead.

If there are no objections, I would rather use a "noGrids" option instead and not define any grid at all, which would do just the same.

[adube]

<displayAllFields>true</displayAllFields>

makes more sense than

<noGrids>true</noGrids>

[yvesm]

W/r to your comment about 'noGrids' : how do you take care of the "have all the fields returned by the query directly displayed instead" use case ? We need a grid or some sort of container for that.

W/r to the ticket in general, 'noFields' seems to me a bit misleading. What it really means is "don't consider the list of fields defined in the widget's configuration" but rather the fields returned in the response. So something like 'responseFields' sounds like a more appropriate name. That way people could configure what fields they want displayed by controlling a server's parameters (e.g. 'gml_include_items' for MapServer or 'attribute_cols' for FeatureServer) and just dump the response fields in the grid/container.

One use case that may be worth considering :suppose your response returns 20 fields of which you are interested in 15, wouldn't it be interesting to say <responseFields>true</responseFields> and then *subtract* fields from the response ? The thing is if you want a fairly large number of fields that happen to be a large subset of the response, you still need to specify them one by one in an additive manner in the widget's configuration. A special case is if you don't have control on the data service; it may be useful to subtract fields from the default response.

Of course, I would keep the current behaviour of additive fields.

[adube]

Replying to yvesm:

W/r to the ticket in general, 'noFields' seems to me a bit misleading. So something like 'responseFields' sounds like a more appropriate name.

'useResponseFields' sounds even better. Thanks for the suggestion.

One use case that may be worth considering :suppose your response returns 20 fields of which you are interested in 15, wouldn't it be interesting to say <responseFields>true</responseFields> and then *subtract* fields from the response ?

I disagree. Defining what you don't want is not intuitive and can have bad side effects. For example, what if the server is updated with 5 new fields ? They're going to be added ! What if we didn't want them ?

IMHO, if we have no control over the service and don't want all fields displayed, we should stick to the idea of defining those we want (like we already do).

[adube]

Patch featuring the new option.

[adube]

Ready for review. The patch features a sample showing the use of the new option.

[adube]

r892, featuring :

• new 'useResponseFields' option for ResultExtGrid widget
• new sample to show the option use

[yvesm]

OK; I was trying to apply the patch and it failed because it required r891. Next time.

[adube]

Yep, that's why I use this very intuitive method of naming the patche files :

patch + project + ticket number + revision of the ticket + version of the patch + .diff

[adube]

"revision of the ticket" ==> should be ==> "revision of the patch"