1 General remarks
@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.
- Make sure all widgets abide by whatever is decided here: GWT widget definitions
- Fix JIRA.... Perhaps this needs a more detailed explanation. We should create a new JIRA project (GWT2) and then see which issues to copy to it (from various projects).
|Plugin: Core Widgets||Oliver + David|
|Plugin: Graphics Editing||JanV|
Who does what? Whenever in doubt: Assign to Frank
2 GWT2 Client
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?
- ViewPort.isInitialized delete this method.
- MapConfiguration.setLayerAnimation => move to LayersModelRenderer:
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?
3.1 Plugin: Core Widgets
CloseableDialogBox, MessageBox, ToolTipBox: Should move to YAWL.
- FeatureSelectBox: Follow widget structure.
Layers and their legends
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:
- org.geomajas.gwt2.widget.client.feature: Widgets that display a single feature in some way.
- org.geomajas.gwt2.widget.client.layer: Widgets that display a single layer in some way. (layer panel showing visibility toggle & legend, table for features, ....)
- org.geomajas.gwt2.widget.client.map: Widgets that display the map (all layers) in some way.
To be discussed: For legend related widgets, I propose the following list:
- org.geomajas.gwt2.widget.client.layer.legend.RasterServerLayerLegend: A widget that displays the legend for a RasterServerLayer.
- org.geomajas.gwt2.widget.client.layer.legend.VectorServerLayerLegend: A widget that displays the legend for a VectorServerLayer. Has the option to react to map events (make itself dynamic).
- org.geomajas.gwt2.widget.client.layer.DefaultLayerPanel: A widget that displays the layer title and a checkbox to toggle visibility. It also displays a legend. (how does it know what legend widget to use???)
- org.geomajas.gwt2.widget.client.map.DefaultLayersModelPanel: A widget that displays a "DefaultLayerPanel" for each layer in the map.
- org.geomajas.gwt2.widget.client.map.DefaultLayersModelDropDown: A widget that displays a DropDown button. When opened, a "DefaultLayersModelPanel" comes out.
3.2 Plugin: Editing
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.
- Split the editing project in client api and server extension.
3.3 Plugin: Geocoder
Widget should follow the rules as explained on Confluence.
3.4 Plugin: Print
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.
3.5 Plugin: Rasterizing
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?
3.6 Plugin: WMS
- Do not let the browser cache WMS GetCapabilities requests (add no-cache headers in the request)
- Add support for Dates in GetFeatureInfo requests (when using the Feature format)
- Add support for dealing with BigDecimal in GetFeatureInfo requests (when using the Feature format)
- Let the client decide if geometries returned through a GetFeatureInfoCommand should be simplified or not (and how many points should be allowed per polygon).
- Automatic check to see if a WMS layer also has WFS support
- Add WFS search mechanism
- Add maximum width parameter to the legend configuration object to limit the width of legend images.
- Initial visibility setting does not work (bug)
- Add support for style changing. The WMS layer must know what styles are available.
- Add legend widget
- ...and many more
3.7 Plugin: Graphics Editing
- This is the link between Graphics project and Editing plugin
- Adding plugin to GWT2 requires renaming of the projects in gwt2 project pom
=> work done, see GGEP-5 branch. This implied re-adding lost class of Editing Plugin: org.geomajas.plugin.editing.gwt.client.GeometryEditorFactory
- Adding graphics editing example jar project to gwt2 example
=> some solution suggested: see GGEP-6 branch. This implied implementing changes of ViewPort in class org.geomajas.plugin.graphicsediting.gwt2.example.client.annotation.AnnotationContainer
- Add Documentation: create new documentation project and fill
- Code has been changed
PURE-119Getting issue details...
, with specific extras to be mentioned:
- renamed code project to geomajas-client-gwt2-plugin-graphicsediting-impl (added -impl) and directory named to impl
- added a new example project. Difference between the two example projects: adding editing functionality via a) object controller b) action (will be shown in cog dropdown menu)
- extended documentation
- TODO: rework the GraphicsEditingUtil class: is now a collection of static values of stroke/fill parameters of polygon/line on creation + a createClickToStopEditService.