[OpenLayers-Dev] OpenLayers 2.8 RC2
C E M Harrison
c.e.m.harrison at cemh.eclipse.co.uk
Wed May 13 20:14:11 EDT 2009
Chris and group,
Please see below, noting:
1) AFAIAA, in every case where I have been asked to provide a minimised
version demonstrating a problem, I have done so.
2) The problems that I have reported are in final applications because ...
> We invite you to help us test the 2.8 release candidate!
... and it doesn't matter how well a piece of code performs in a limited
environment, no end user is ever going to see it working, if it breaks in
the more stressful environment of a final application.
> Your test cases, included below, and previously used many times in
> comments, are not minimized. There is no way that I am going to read
> through 150kb of code to find a bug.
As above, in every case where I have been asked to provide a minimised
version demonstrating the problem, I have done so.
> I see no such notes on either page
Just click 'Notes'.
> nor do I even see a map
> on either
Just click the Google map button.
> FF has changed several times in the last 6 months. It would not be the
> first time that changes in the underlying browser have introduced new
I agree that it might be changes in FF3 that are triggering the new
problems, especially as this one now appears under /api/ as well (and didn't
when I first created the page). Nevertheless, as my bug report notes, there
is a *history* of this problem with OL. It has often been claimed that it
has been fixed, but it is clear from its constant recurrence that the root
of the problem has somehow not been cured.
> Set up two pages side by side with the minimal possible
> number of lines
> of code to resolve this problem.
In my last posts to the bug report, I've detailed out clearly and simply how
to replicate this problem using a relatively simple test page.
> > 2) If you choose to print only selected pages in FF3,
> the maps are blank,
> > but if you print the entire document, they print properly.
> It's not clear to me if you are talking about 'blank' in the
> browser, or
> in the printout.
In the printout.
> In the latter case, OpenLayers has never
> sought to make
> printing easy or efficient. There are other tools that you should use,
> and the differences in browser printing make the idea of doing so
> completely impractical.
I cannot accept such an illogical argument. Yes, there are too many
differences in browser printing, just as there too many differences in
browsers screen output, but printing is as valid a means of output as
screen, and is supported under HTML, CSS, etc. You can't say you don't
support it because of browser differences without implying that you don't
support output to screen for the same reason.
> > 3) Still in FF3, in the Satellite Calculator, if you
> print the Hybrid Base
> > Layer, the marker is broken - literally, it prints in
> several sections,
> > which seem to coincide with different tiles, and which may
> not be colinear
> > or even all point the same direction! However, if you
> reload and select the
> > Satellite Baselayer, that prints correctly, just as the
> Hybrid Base Layer
> > used to do. Again, the logic of that completely escapes me.
> It sounds like you are talking about behavior with printing on top of
> Google Maps inside OpenLayers. That is *far* beyond the level of
> functionality that we have put any effort into making work. In this
> case, not only could the OpenLayers library be at fault -- so
> could the
> Google library, which changes on semi-monthly basis. Without a direct
> 2.7 to 2.8-rc comparison, it is impossible to pin this type of problem
Although I haven't put details in a bug report on this yet, I can reproduce
this in a relatively simple test page.
> > In summary, as far as I am concerned, there seem to be more
> problems using
> > OL maps now under RC2 than there were six months ago under
> 2.7, though how
> > much is due to say, poorly tested FF version updates, and
> how much to RC2, I
> > can't say for sure. But I desparately need RC2 to deliver
> much needed
> > greater reliability, not less.
> If you need something, you are always welcome to create patches and
> attach them to tickets.
I want to spend my limited time on this earth in creating something useful
of my own, rather than fixing other people's code. I have noted in one of
the bug reports in which I have participated that I have on occasion looked
to provide fixes, but have been deterred by the lack of proper encapsulation
in existing code which good OOP should bring, and in fact with that
particular problem I very quickly realised that the quickest way to fix it
would probably have been to start over with two of the most important
classes in the heirarchy, and I didn't think the OL community would likely
appreciate that. While not all problems are as complex as that one, the
ones that badly affect my applications do seem to be fairly complex, but
that may imply just that I manage to find fixes for the simple ones for
> It is in your best interest to make your issues small. Small
> issues are
> easier to deal with.
But if they are of the type that mainly occur in big applications - memory
management, etc - where does that leave OL users?
> Your existing large pages do not, in general,
> provide concise test cases to determine the source of problems
The new FF3 print preview problem, and actually the broken marker with
Hybrid Base Layer problem which I don't think I've yet logged in either an
existing or a new bug, are both reproducible in a relatively simple test
page (the main complexity of which is providing the logging information in
the right-hand window - the map and marker creation itself is only about
75 lines, 20 of which are blank or comments).
More information about the Dev