Al, we talked about your ideas in the last team meeting. As I already suspected, loadWfsRequests() is a remainder from times when we had no vector layers. It was a hack, because it breaks the MVC rule that a model should never populate itself, but be populated by a control (ie. "tool" in Mapbuilder). loadWfsRequests() should be entirely removed from FeatureCollection.
I would suggest you use your code as-is in custom widgets - you can always have your own lib dir and say <scriptFile>...</scriptFile> in your config.xml. Anyway, you could still stick with stock Mapbuilder and do as I suggested: define your wfs data source by get parameters as defaultModelUrl in a FeatureCollection model. Then it will be available without specifying it in the context file. This would be easiest in your case, as long as you do not have a specific reason for having your featuretpye specification in the owscontext. Or you might write a tool that pulls the wfs featuretype config from the context and populates the FeatureCollection with the wfs response. In this case, the featuretype in the context should be marked hidden, because it will be rendered by GmlRendererOL instead of MapPaneOL. You cannot use the default legend widget in this setup, because if you switch the featuretype to visible, it will also be painted by MapPaneOL and then you have it twice in your map. This concept might even be thought further: MapPaneOL could check if a featuretype is registered for rendering by a GmlRendererOL, and in this case never render it. Show/hide action from the legend widget would then also have to be dispatched to the GmlRendererOL. Regards, Andreas. On 7/19/07, Al Byers <[EMAIL PROTECTED]> wrote: > Andreas, > > I am sort of beat, but I wanted to get this diff to you. I guess the two > questions are: > > 1. Is my method for coordinating the initialization of GmlRendererOL and the > adding of a listener in FeatureCollections correct. > > 2. Is the use of featureTagName and the mods to wfsLoadRequests correct? > > -Al ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ mapbuilder-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
