From: Rural H. <rur...@gm...> - 2017-06-20 07:14:04
|
Seems fine to me. We use customized new BrowserVersions instead of setters to change the default BrowserVersions if we want to change some browser properties. 在 2017/6/17 3:15, Ronald Brill 写道: > Hi HtmlUnit users, hi HtmlUnit developers, > > it looks like we have currently a major design flaw with the way HtmlUnit handles different browser versions. > > The problem is in short: > * the final browser setup is done by different technics; getter/setter in class BrowserVersion, Jsx annotations and constants in BrowserVersionFeatures > * the user is able to define (clone) browser versions but in the end only limited parts of the setup is realy changeable; this has lead to some wrong expectations and > misunderstanding in the past > * the browser version is used inside the code without taking care of this cloned versions and this might be the root of some errors we got > * it is possible to change parts of the BrowserVersion at a later point, the code is not aware of this and does strange things > > Because i think we are not able to fix this in a backward compatible manner i like to discuss possible solutions here. > > Suggestions: > * it will still be possible for the user to create browser versions based on the existing ones > * the user can only configure the part of the browser setup that is configurable at the moment by using the setters in BrowserVersion > * to avoid problems and later changes of the BrowserVersion we will support this by using a builder pattern similar to this > > BrowserVersionBuilder builder = new BrowserVersionBuilder(BrowserVersion.CROME); > builder.setPlatform("BeOS"); > .... > BrowserVersion myBeBrowser = builder.build(); > > new WebClient(myBeBrowser); > > ** if there is an BrowserVersion with exact the same setup as your Builder is asking for, this will return the already existing BrowserVersion > ** using the BrowserVersionBuilder you will have similar options as you have today for the BrowserVersion > ** it is no longer possible to change the BrowserVersion itself because the setters are longer available > > This will have some imlications for you current code: > > * HtmlUnit will internally maintain a list of browsers - mabe you can get a browser from this list by name > * BrowserVersion will be fixed if you finished with the setup, it will not be possible to change the configuration later on (this is possible today but will definitly introduce trouble > for you) > * you have to adapt your code > * It seems to be possible to introduce this change the usual way by making the existing API deprecated and remove with later versions > > What do you think. > Is this ok for our brave users? Do you need support for more? > Any better ideas/suggestions/improvements? > > > RBRi > -------------------------- > WETATOR > Smart web application testing > http://www.wetator.org > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Htmlunit-user mailing list > Htm...@li... > https://lists.sourceforge.net/lists/listinfo/htmlunit-user > |