Hi Al, On 7/17/07, Al Byers <[EMAIL PROTECTED]> wrote: > OK, but I need FeatureCollection.loadWfsRequests to be run > and it is not added unless FeatureCollection.containerModel > is set and it is not.
Ok, so let me explain what this containerModel thing is all about: basically, it is a deprecated concept from the pre-OpenLayers era. The idea of it was to allow for widgets to share an output model, but have their own models to derive the content from. There are still some remains of it, and they are handled by setting the containerModel to the targetModel of a widget that shares the same container for its output, eg. GmlRendererOL. In your specific config, the containerModel might not yet be set when FeatureCollection initializes, because GmlRendererOL is initialized after FeatureCollection. So the event handler for containerModel.loadModel will not be registered. So what you did in your config, which is correct, is to add GmlRendererOL to the FeatureCollection model, and set the targetModel of GmlRendererOL to your map context. And now comes what I believe is your mistake: you do not need GmlRendererOL to just render WFS layers. If you add a FeatureType to your context, it will be rendered as vector layer directly by OpenLayers. What you need GmlRendererOL for, is to render arbitrary data sources that can be transformed to a wfs FeatureCollection, and do feature hover/click handling on them. > Furthermore, the > FeatureCollection.containerModel needs to be a > wmc:OWSContext in order for loadWfsRequests to work. It looks like > FeatureCollection needs containerModel set the same as GmlRenderOL. Or do > the loadWfsRequests and convertCoords functions need to go in GmlRenderOL? Not exactly, because GmlRendererOL has the purpose to render its parent model, which is a or has to be transformed to a wfs FeatureCollection. I know that the current concept of all this has the shortcoming of not being able to use FeatureSelectHandler on FeatureTypes from the context. The reason for this is that neither SVG nor VML support event handling through z-indices. This means that only the uppermost SVG/VML layer can fire hover/click events. And in an OwsContext, where by design layers, feature types and others are stacked in different z-indices, this will not work. I do not know your exact use case, but from looking at your config files I would suggest to do the following: - add wfs data sources that you just want to display to your OwsContext - make a single FeatureCollection for each of your wfs data sources that you want to do FeatureSelect handling on. You can either directly load them into the featureCollection by specifying them as defaultModelURL (like in the shipTracks demo), or define the featureCollection as a transactionResponse model which gets filled by WfsGetFeature (like in the wfs-t demo). If I interpret your config correctly, you have a static filter query on your wfs data source. Most wfs services allow putting the filter into the get url, so this should work for you. You do not need to specify the FeatureType in your OWSContext then. > So this leads me to believe that GmlRenderOL must implement the > loadWfsRequests and convertCoords listeners. At least the loadModel event on the OwsContext would have to be set in GmlRendererOL. But I think that loadWfsRequests is a remainder from the pre-OpenLayers era, and I would think that the following way would be more useful: - Specify featureTypes in OwsContext as hidden - Link a FeatureCollection to a single featureType in the OwsContext by a config property - Load the linked featureType into the model - If needed, multiple featureTypes can be combined using MergeModel. But these would be major changes that have to be discussed in the PSC, and I am afraid this will not happen before 1.5alpha2 release. Regards, Andreas. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ mapbuilder-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
