It sounds like a great idea, and it actually works for Python. However, since OpenLayers extensively use subclassing, won't this be a problem, if one were to make WFS3 it might be required to also make Layer3, Grid3, etc?
I can also see that the Map and Layer classes are tightly coupled, so I forsee trouble there. Will there be extra development to allow a Map3 to support a Layer, and vice versa for Layer3 and Map? Regards, Kenneth Skovhede, GEOGRAF A/S Christopher Schmidt skrev: > Yo, > > I've had a couple one-off conversations about this, but not one has > been in a public, archived location for everyone to read, I've realized. > > There are a number of significant refactorings we have planned for > "OpenLayers 3.0". This is expected: as I said during my presentations in > Japan, "We've learned a lot in two years"... pointing out that 2 years > ago I'd never used a WMS (OpenLayers was my first), knew nothing about > projections, and the idea of EPSG:900913 didn't even exist. > > So, we have some significant refactoring/changes to make. Cool. However, > one problem has always been that major refactorings all at once tend to > make things hard -- the 2.4 release was in testing/RC for 6 weeks > because of the huge number of things that we tried to pack in all at > once. > > At one point in the past, I suggested that we target a method like the > one used by the Python 3.0 development team: Target creating a 'final' > OpenLayers release that had a 'compatibility mode' with OpenLayers 3.0. > In 2.x mode, everything would continue to work as it does now. In 3.0 > mode, you would get errors -- preferably things like "You really need to > not be using the MouseToolbar class -- it's gone now, use NavToolbar > instead" -- that would tell you what was about to change. > > This would require having a pretty strong knowledge of what is going to > be in 3.0 before we actually get there -- meaning we'll need some > parallel development. > > I believe that at least some of the changes that we're talking about are > possible to implement within the framework of 2.x -- though admittedly > with some more code. For example, one of the things that I think people > have been talking about is a single renderer root for SVG/VML. My vague > guess is that this would require changes to all of the renderer related > classes. It might also require changes to the Vector Layer, and some > other things -- like different controls or something. > > However, it seems likely that since we'll want to provide transition > support, we can do this refactoring in something like a Renderer3 class > hierarchy (and similar for other classes). > > If we do this, then upgrading to 3.0 functionality is similar to "from > future import generators" -- simply use the newer classnames in your > code. > > Clearly, we wouldn't neccesarily be in a position to upgrade *all* code > in that way -- and as we do the development, we can keep information > about stuff that has or has not been upgraded. (This information will be > informative/'required' for transitioning later, anyway.) > > Then, when we're ready to release 3.0, the transition isn't too painful: > we simply move the "3" classes back in place of the "2" classes. > > I don't want to limit development of OpenLayers 3.0 -- but the idea of a > "code sprint for 3.0" as has been mentioned does definitely scare me if > it's done in the way we did the vector work. > > Perhaps my estimation of the depth of changes needed for some 3.0 work > is too shallow, and this makes my proposal difficult, but what I'd > really love to see is: > > * putting together a branch for various 3.0 features > * Developing them > * Figuring out how to put the features into 2.x as something people > can explicitly choose -- not in the API, but as a way of letting us > use them now, and get development/testing on them without waiting for > one big changeover of applications. > > Are there features that we can do this for? Are there features we can't > do this for? > > I think one case of the latter *might* be the baselayer/overlay > dichotomy fixing -- but even that feels like it could be fixed to some > extent in an OpenLayers.Map3 class, maybe -- and maybe we don't go ahead > and change all the layers to work in a new way, but instead, create a > couple (Google, WMS) and then apply those changes to other layers as we > do the upgrade to 3.0. > > Thoughts? > > Regards, > _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
