Re: Problems with BrowserVersion - Feedback required

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Problems with BrowserVersion - Feedback required

RuralHunter
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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/htmlunit-user
>


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/htmlunit-user