@since declaration needs to be 2.0.0 everywhere! It also needs to be removed from any methods, but only appear on class/interface definitions.
| What? | Who? |
|---|---|
| Touch Support | Dosi |
| GWT API/Impl | Pieter |
| Plugin: Core Widgets | Oliver + David |
| Plugin: Editing | ? |
| Plugin: Geocoder | ? |
| Plugin: Print | JanDM |
| Plugin: Rasterizing | Frank |
| Plugin: WMS | Pieter |
| Plugin: Graphics Editing | JanV |
Who does what? Whenever in doubt: Assign to Frank
Should CanvasContainer and CanvasShape be a part of the API? Can it be removed? In the long run, we could replace it with some sort of client-side layer that has a Canvas based renderer. Should be added to a ContainerManager interface which groups all containers
TransformableWidgetContainer: same remark as CanvasContainer. Should be added to a ContainerManager interface which groups all containers.
Tile and TileCode: they are placed under the package gfx. Is that the correct place?
Reverse the names MapConfiguration and MapOptions:
Should the MapHint system be presented through a singleton service instead of map specific?
Remove OpacitySupported? I believe the opacity changing should be a part of any layer:
Replace HasLegendWidget with a factory system?
What is the EntryPoint for? Remove it?
The touch controllers have been disabled since the animated navigation. They should be adapted and tested again. Otherwise we should remove them.
Add setInstance method to GeomajasServerExtension
GeomajasServerExtension.createLayer should return a ServerLayer instance.
Rename MapOptionsExt to MapConfigurationExt?
Do we really need an ExceptionDialog widget here?
CloseableDialogBox, MessageBox, ToolTipBox: Should move to YAWL.
Different layers may build their legends in different ways. Many widgets may exist that build legends for certain layers. How can the DefaultLayerPanel for example, know which widget to use? I think we need a factory system that helps determine how to build a legend for a certain layer. The default may simply build an Image widget from layers that have LegendUrlSupported. Then extra factories, stored in some registry may build legend widgets for other layer types.
To be discussed
To be discussed: At this point I would like to propose we create the following base packages wherein all widgets should come:
To be discussed: For legend related widgets, I propose the following list:
Very unclear API. Also remove all references to @FutureApi.
Revisit the GeometryEditor construct.
Split up the examples
Examples contains a GeometryToShape converter. Should that not be a part of the Geomajas client API?
What SnappingAlgorithms should be part of the API? Do we need a factory to shield the implementations from API? => Only 2: NearestEdgeSnapAlgorithm, NearestVertexSnapAlgorithm
What's the purpose of the GeometryOperationService? How is it connected to the rest? Move to geomajas-server-extension? Same with splitting and merging?
Shouldn't we call this “geometry editing”? It's more to the point.
Widget should follow the rules as explained on Confluence.
Is it Print or Printing? We should rename where necessary.
There is a default template builder, but no easy way to provide your own templates. Should we not provide a template building API? Some factories perhaps.
Wat is the PrintingLayout? Seems like a SmartGWT construct.
PrintPanel: should follow widget rules.
PrintingMessages: Place it in a i18n folder.
Refactor Printing into a starting point for creating a print service and template etc. It should not be an EntryPoint.
Almost no @Api annotations (only in the PrintingLayout).
There are no examples yet.
I don't understand the need for this plugin. Does it need to override the .gwt.xml definitions of something else? Should this not be a part of the GWT2-ServerExtension?