Marble/GraphicsViewGeoParser: Difference between revisions

Revision as of 22:10, 22 July 2009

GeoParser and the GeoGraphicsView

The current GeoData XML Parser ( aka. GeoParser ) has been implemented to specifically deal with our current GeoData data structure. If you want to see a more complete documentation of the GeoData library you can see the GeoData documentation. I will only describe the particular problem to the GeoGraphicsView implementation here.

Casting

The unfortunate thing about the current implementation of the GeoParser is that when any item is added to the Collection Data Structure it is effectively cast as an GeoNode and removes any ability for 3rd party developers to add parsing capability to marble with functionality other than that which marble provides. This is an issue that needs more investigation to provide more flexibility.

Link between GeoData and GeoGraphicsItems

Previously, GeoData has been accessed through pointers from the rendering objects. this poses problems as GeoData uses data sharing and updates in GeoData are thus not seen in Items.

It could be possible to do multiple inheritance where GeoGraphicsItems would also be GeoNodes, but that raises issues regarding modularity, because both the model and its representation would be in the same object.

The better solution would follow an observer pattern logic whereas GeoGraphicsItems would react to GeoData. Multiple options are available:

use signal/slots
implement light event handling methods
use qt's model-view framework of model-view-ng

@@ Line 1: / Line 1: @@
 == GeoParser and the GeoGraphicsView ==
-The current GeoData XML Parser ( aka. GeoParser ) has been implemented to specifically deal with our current GeoData data structure. If you want to see a more complete documentation of the GeoData library you can see the [[Projects/Marble/LibGeoData|GeoData Library documentation]]. I will only describe the particular problem to the GeoGraphicsView implementation here.
+The current GeoData XML Parser ( aka. GeoParser ) has been implemented to specifically deal with our current GeoData data structure. If you want to see a more complete documentation of the GeoData library you can see the [[Projects/Marble/GeoData|GeoData documentation]]. I will only describe the particular problem to the GeoGraphicsView implementation here.
-<!-- move this section to a dedicated "How the XML parser works" section -->
+=== Casting ===
-=== Parsing GeoData ===
+The unfortunate thing about the current implementation of the GeoParser is that when any item is added to the Collection Data Structure it is effectively cast as an {{class|GeoNode|kdeedu|4.2}} and removes any ability for 3rd party developers to add parsing capability to marble with functionality other than that which marble provides. This is an issue that needs more investigation to provide more flexibility.
-The GeoParser is an implementation of the QXMLStreamReader class in Qt, more information can be found [http://doc.qtsoftware.com/4.5/qtxml.html here]. There are other things built into this implementation that simplify the creation of a parser for new XML format document, namely:
-* The Concept of a TagHandler class that deals with only one tag
-* A Stack Item class that implements the Structural parts of the XML document
-* The collection class where the results of the XML parsing will be placed
-* A element dictionary that prevents the need for string comparison everywere
-To implement a new XML parser you need to
+=== Link between GeoData and GeoGraphicsItems ===
-#compile an element dictionary of all of the available tags in the namespace
+Previously, GeoData has been accessed through pointers from the rendering objects. this poses problems as GeoData uses data sharing and updates in GeoData are thus not seen in Items.
-#implement a tag handler for each of these elements
-#register that tag handler with the GeoParser
-==== Implementing a tag handler ====
+It could be possible to do multiple inheritance where GeoGraphicsItems would also be GeoNodes, but that raises issues regarding modularity, because both the model and its representation would be in the same object.
-Each tag handler is called when the relevant XML tag is reached by the GeoParser ( which knows what tags to call by its registered tag list ). Each tag can access the stack data structure of the GeoParser as well as the Collection Data Structure of the GeoParser. This allows the tag handler to access items from the stack and allows root elements of the XML to add themselves to the collection data structure.
-<!-- more information needed when moved to its own page -->
-=== Down Casting ===
+The better solution would follow an [http://en.wikipedia.org/wiki/Observer_pattern observer pattern] logic whereas GeoGraphicsItems would react to GeoData. Multiple options are available:
-The unfortunate thing about the current implementation of the GeoParser is that when any item is added to the Collection Data Structure it is effectively downcast to the collection's type and removes any ability for 3rd party developers to add parsing capability to marble with functionality other than that which marble provides. This is not in line with the design of the QGraphicsItem implementation and something that is a current development effort to fix. What needs to happen is that an extra data model needs to be added to the GeoParser that is more in line with the idea of passing pointers around and that way we can conserve the typing information at run time.
+* use signal/slots
+* implement light event handling methods
+* use qt's model-view framework of model-view-ng