SelectionPanel: Capability to customize display results

[aboudreault]

I think it would great to be able to customize the display of results when a selection has been made. The original SelectionPanel will probably be enough for most users who will only add their CSS style. However I think that a lot of users would be happy to be able to customize the display results to produce their own query results. For exemple, a user may wants all the results in a simple table which contains one <tr> per features and one <td> per attributes. Another great feature would be the support of setting something like: 10 features per page, with a next/prev button. Basicly, the proposed solution is the following:

• Create a more flexible widget that will let the user define his function to render the features The user will write his own javascript function which will produce the html.

• (Future?) Add a setting in the ApplicationDefinition.xml to specify the number of results per pages and functions that would return the results of the current/previous/next page.

[pagameba]

Alan, I think the existing API can be used and there doesn't need to be a new widget. At the end of the MapGuideTutorial is a description of how to use the selection API (not sure if it is up to date) - this should be rewritten as a cookbook recipe and users wanting to customize the selection output could start there. The new recipe should include a complete functional example that can be added to a Fusion application outside of the widget structure.

What do you think?

[assefa]

I tend to agree that multitudes/custom widgets should be avoided. But saying that I consider the SelectionPanel provided with Fusion too limiting. Allowing few settings like presentation of results horizontal/vertical, number of results per page would go a long way for users. In fact I see the number of results per page as almost a necessary feature since it can avoid transfer of enormous amount of selection results from the server. Yes the user should learn the api but also basic out of the box fusion functionalities should not be discarded when they make sense.

The underlying api for get selection allows to retrieve chunks for the selection already and I think It should be used by the default SelectionPanel

[pagameba]

Ok, I agree with adding some customization to the SelectionPanel. Assefa is absolutely correct that the underlying API supports fetching results in batches (pagination) and that we are not taking advantage of it in this widget. I think it would be enough to specify the options in the ApplicationDefinition rather than have a user-control for that. I'm not sure about switching from vertical to horizontal orientation but it should be relatively straight forward to add that too.

[aboudreault]

I agree, the existing API would do the job. I didn't see this part of the code. So, i think the SelectionPanel widget should use it at best it can. It needs to allow us to set the user function that will process the results and support results in batches (good to hear that the api already support it). If no default function is provided by the user, the widget will just uses the current display (with combobox, etc.). Also, this selection documentation would have it own part somewhere, and not only in the mapguide specific section.

[aboudreault]

In fact, instead of "Create a more flexible widget...", we can only modify the existing widget to add these functionnalities. This is basicly what i wanted to do but didn't know that the selection api support most of what we want to do. What do you think?

[pagameba]

Yes! I agree we should enhance the current widget to support more customization rather than create a new one. I have some other customizations that I would like to go into the selection panel too, but they are not about customizing the display results so I will leave them for another day.

In summary, we are proposing to:

1) add ability to paginate results through a setting in the ApplicationDefinition, probably by setting a ResultsPerPage (name to be discussed) value in the Extension tag

2) Customize display, the two suggestions above seem to be as follows. Not sure if we should pick one or if both could be options.

a) add ability to set the layout to horizontal (all results in a table, one result per row) or vertical (one result in a table with the ability to change the current record),

b) provide a javascript callback function that formats the selection result.

[jlacroix]

I think both 2a and 2b could live together.

Actually, 2a seems to be the current behavior, adding the ability to display all the results (with or without pagination) is just a bonus. The format callback function is necessary anyway. The right way to go is probably to implement the callback and use it to implement the default behavior.

My $0.02

[aboudreault]

Ok, i've made some work in the SelectionPanel...... but i would like to have your opinion. I've complety removed the dependency between the SelectionPanel and the default behavior. In fact, i've create an abstract class called Fusion.Widget.SelectionPanel.SelectionRenderer (name to be discussed) to define A behavior when a selection is done and off course an default selection renderer class that inherit from this class. This doesn't increase the complexity of the SelectionPanel at all. If nothing is specified in the ApplicationDefinition, the default behavior will be used. Now, 2 new possibilities are now available:

• Pass a simple callback function to the SelectionPanel
  A simple function can be passed to the widget, and binded with MAP_SELECTION_ON (Like your example in the MapGuideTutorial).
  
  
• Pass a complex behavior created by a programmer
  A experimented programmer will be able to create his own SelectionRenderer class. This part Fusion can be very complex and different for each user (IE: a user may needs to make something at initialization of the widget (like the default behavior), create his own events, define his own clearSelection method, display results in others windows, etc.) So, the user will create his own behavior with the SelectionRenderer class and just pass it to the SelectionPanel via the ApplicationDefinition.

I really don't know if you'll like the idea... i'm waiting your comments.

[aboudreault]

I've commited a first version in my sandbox with the pagination supported (but it needs to be fully tested)

[pagameba]

I haven't looked at the code yet but I love this idea! I'm now wondering if the same pattern can be extended to other widgets.

[aboudreault]

Ok, i just commited another version of the SelectionPanel widget in my sandbox. I created a renderer that produce tables with all results and their attributes (see the image i've attached). The pagination is also supported and tested. If you have some improvements to do , no problem.

I'm wondering if we need to allow the user to choose a layout in the ApplicationDefinition (Horizontal of vertical: the default one) or simply let the user define his renderer function/class like the widget does actually. If not, we can remove the Horizontal renderer from Fusion and i'll use it for make a HowTo.

[madair]

I've had a look at this and the implementation looks good. I've tested for both MapServer and MapGuide, in IE and FF. Other than an extra comma problem I would recommend adding this to the trunk.

[dmorissette]

So what's the next step? Can Alan go ahead and commit this to trunk or does it have to be done by one of you (Mike/Paul)?

[pagameba]

Alan, please correct the extra comma issue and commit.

[aboudreault]

Committed to SVN trunk r1466

[madair]

(In [1474]) re #71: added missing 'this'

[madair]

(In [1475]) re #71: added missing 'this' - trunk