Panel: decouple the appearance of the icons to the Controls

[jorix]

When a panel manages visual controls (such as another panel)"DOM" attributes in icons and controls are mixed. The clearest example is the "title".

The ticket proposes:

• Can specify different values for title and "displayclass" for the icon.
• New property "CSSClasses" only for icons, to separate the additional classes from "displayclass", this allows a declaration of controls clearer.

Implementation: Proposes a new property "panelIcon - {Object}" in control.js. To create a control "panelIcon" contains all the specific properties of the icon.

The patch includes changes into example "panel.html":

• Adapted to new: wiki/CodingStandards#WritingExamples.
• Remove needless CSS to improve appearance.
• Show the usage of TYPE_TOGGLE controls.
• Change deprecated MouseDefaults control by Navigation
• Show the usage of the new property "panelIcon".

It includes new test for the properties into "panelIcon" object.

This patch is independent of #2863, but is designed to work together.

[jorix]

Test ok in: FF36, IE8, CHR6 & SF5

This patch is also the basis for two patches for panel in which I work:

• Hide icons.
• Icons with adjustable width and highlighted background to put above texts or images.

[erilem]

With the current design panels aren't meant to include UI controls, panels create buttons/toggles for non-UI controls. So the current rule is don't use panels for composing UI controls. I don't think we should attempt to change that design, at least not for 2.11. I'm therefore bumping this ticket to 2.12, please change it back to 2.11 and provide explanations if my comments don't make sense.

[jorix]

Replying to erilem:

With the current design panels aren't meant to include UI controls, panels create buttons/toggles for non-UI controls. So the current rule is don't use panels for composing UI controls. I don't think we should attempt to change that design, at least not for 2.11. I'm therefore bumping this ticket to 2.12, please change it back to 2.11 and provide explanations if my comments don't make sense.

In the customization that I did use a toggle to measure that is associated with a sub panel with two buttons: areas and surfaces.

This made ​​me think about that possibility, but it is a proposal that has long been sleeping...

(What's more, I have written unpublished code to use text buttons with background on/off, using the object PanelIcon proposed here. But this if it would be 2.12)

[erilem]

Replying to jorix:

In the customization that I did use a toggle to measure that is associated with a sub panel with two buttons: areas and surfaces.

Sorry, I'm having trouble understanding you here.

[bartvde]

Maybe he means something similar to how measure is used in GeoExplorer:  http://suite.opengeo.org/geoexplorer/

However, I agree this goes too far for OpenLayers, and this is really the boundary where people should be using UI frameworks instead IMHO.

[jorix]

Replying to bartvde:

Maybe he means something similar to how measure is used in GeoExplorer:  http://suite.opengeo.org/geoexplorer/ However, I agree this goes too far for OpenLayers, and this is really the boundary where people should be using UI frameworks instead IMHO.

Yes, but with simple elements:  http://www.castelldefels.org/ca/mapes.asp?lang=en

[jorix]

Merged with the current SVN and simplified example.

[jorix]

attachment:2862.2.patch : Merged with the current SVN and simplified example.

In the examples/panel.html is proposed to add Control.MousePosition in the panel to show how to use the new property panelIcon proposed in this ticket. Also made ​​a few visual tweaks to improve the appearance of this example.

NOTE: In the new patch is deleted "CSSClasses" proposal because it has no meaning without applying the "olControlStartGroup" and "olControlEndGroup" proposed in #2946

[jorix]

Merged with current trunk and more tests

[jorix]

Replying to erilem:

With the current design panels aren't meant to include UI controls, panels create buttons/toggles for non-UI controls. So the current rule is don't use panels for composing UI controls. I don't think we should attempt to change that design, at least not for 2.11. I'm therefore bumping this ticket to 2.12, please change it back to 2.11 and provide explanations if my comments don't make sense.

The proposal of this improvement is not breaking the previous behavior, and it gives more flexibility in the design of the panels. It also gives the possibility of extending the use of panelIcon for new properties of the icons (I think for example: text icons).

After updated with the trunk and add more test I put in revision for 2.12

[jorix]

Can address this problem by overriding the method Panel.createControlMarkup proposed in  pull/223, so this ticket can be closed as duplicate.